Double lock on wxMutex(wxMUTEX_DEFAULT) allowed?

[Vadim Zeitlin]

On Tue, 2 Oct 2007 18:51:37 +0200 Alexander Steffens <steffens at math.uni-bonn.de> wrote:

AS> shouldn't it be possible to workaround that like following sketchcode
AS> within wxMutex::TryLock in the non recursive case on MSW?
AS> Or are I absolutely naive?
AS> 
AS> 
AS> //----------------
AS> wxMutexError
AS> wxMutexMSW::TryLock() {
AS> 
AS>     //first do MSW-stuff as before
AS>     wxMutexError error = TryLock_old();
AS> 
AS>    if(wxMUTEX_NO_ERROR != error)
AS>        return error;
AS> 
AS>       //now we are sure that no other thread than current thread
AS>       //is inside this part.
AS>       //because we are the current thread we can not be here twice.
AS>       //therefore we are alone even if TryLock_old is recursive.
AS> 
AS>       //now we check if we was here with the current thread
AS>       //for an unlocked lock before. If yes would have a dead_lock
AS>       //if we think in the non-recursive way.
AS> 
AS>       unsigned long thread_id = wxThread::GetCurrentId();
AS> 
AS>       if(m_hmpLockedByThread.find( thread_id ) == m_hmpLockedByThread.end() {
AS>          //ok we are here for the first lock with this thread
AS>          m_hmpLockedByThread.insert(thread_id);
AS>          return wxMUTEX_NO_ERROR;
AS>       }
AS>       else {
AS>          return wxMUTEX_DEAD_LOCK;
AS>       }
AS> }

 I think that something like this could indeed be done for TryLock() (you'd
presumably need to unlock the mutex before returning wxMUTEX_DEAD_LOCK
though). However I think Lock() is used much, much more often than
TryLock() so it would be actually more important to do it there -- why did
you choose TryLock()?

AS> I think it would be fine do something like that within wxMutex, else
AS> most users have to handle the incompatible behaviour between some
AS> unixes and windows in their app.

 We probably should indeed implement such check in debug build. I don't
think we want to do it in release as a multi-threaded program may perform a
lot of operations with mutexes and adding even a couple of map lookups to
each of them may be noticeable.
 
 It's also really unfortunate that you can't find the handle of the thread
which currently owns the mutex (unlike the critical sections which do
contain this information). In fact I keep hoping that there is a way to do
it but so far I wasn't able to find it.

 Regards,
VZ

-- 
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/