RE: [reSIProcate] Mutex.cpp and RecursiveMutex.cpp Implementation s for Win32
For windows: I've implemented both Mutex.cpp and RecusiveMutex.cpp using
windows CriticalSections. Changes are checked in.
-----Original Message-----
From: Scott Godin
Sent: Thursday, June 17, 2004 10:40 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Cc: 'david Butcher'; 'Ken Kittlitz'
Subject: RE: [reSIProcate] Mutex.cpp and RecursiveMutex.cpp Implementation s
for Win32
I just want to clarify my understanding of the purpose of the RecursiveMutex
class. I am assuming the intent of this class is to provide a Mutex
implementation that is re-entrant by a thread. Ie. If the same thread
locks the same mutex twice it will not deadlock. If this is correct then
this is the default behavior of Windows Mutex implementation. See the
following from MSDN:
"The thread that owns a mutex can specify the same mutex in repeated wait
function calls without blocking its execution. Typically, you would not wait
repeatedly for the same mutex, but this mechanism prevents a thread from
deadlocking itself while waiting for a mutex that it already owns. However,
to release its ownership, the thread must call ReleaseMutex once for each
time that the mutex satisfied a wait."
Also - I was considering changing the implementation of Mutex to using
windows Critical Sections, which are also thread re-entrant and are supposed
to be more efficient. See the following from MSDN:
"Critical section objects provide synchronization similar to that provided
by mutex objects, except that critical section objects can be used only by
the threads of a single process. Event, mutex, and semaphore objects can
also be used in a single-process application, but critical section objects
provide a slightly faster, more efficient mechanism for mutual-exclusion
synchronization (a processor-specific test and set instruction). Like a
mutex object, a critical section object can be owned by only one thread at a
time, which makes it useful for protecting a shared resource from
simultaneous access. There is no guarantee about the order in which threads
will obtain ownership of the critical section, however, the system will be
fair to all threads. Unlike a mutex object, there is no way to tell whether
a critical section has been abandoned. .....
Once a thread owns a critical section, it can make additional calls to
EnterCriticalSection or TryEnterCriticalSection without blocking its
execution. This prevents a thread from deadlocking itself while waiting for
a critical section that it already owns."
Any thoughts?
Thanks,
Scott