Recursive mutex
Article Metadata
Implementing recursive mutexes.
(Note that Symbian 9 mutexes are recursive, so this applies to pre-v9)
If you come from a POSIX environment, you'll find Symbian's support for synchronization primitives rather simplistic. This is in some way due to Symbian's preference for single threaded applications using the Active Object idiom, thus making the use of multithreading often unnecessary. Sometimes, the need for recursive (reentrant) mutexes arises (note though that POSIX mutexes aren't recursive by default). Here is a possible implementation of a wrapper class over a RMutex:
class CRecursiveMutex : public CBase
{
public:
CRecursiveMutex();
~CRecursiveMutex();
void Acquire();
void Release();
private:
RMutex iMutex;
TThreadId iOwner;
TInt iCount;
};
CRecursiveMutex::CRecursiveMutex() : iCount(0)
{
iMutex.CreateLocal();
}
CRecursiveMutex::~CRecursiveMutex()
{
iMutex.Close();
}
void CRecursiveMutex::Acquire()
{
TThreadId id = RThread().Id();
if (iOwner == id)
{
++iCount;
}
else
{
iMutex.Wait();
iCount = 1;
iOwner = id;
}
}
void CRecursiveMutex::Release()
{
if (--iCount == 0)
{
iOwner = 0;
iMutex.Signal();
}
}
You'll notice this is a bare bones implementation. Potential things to be added (at least on debug builds) could be checking thread ownership and iCount being 0 upon destruction.
12 Sep
2009
This article had explained about the Recursive Mutex we know about recursive function ,Recursive function means a function which call by it self is called a recursive function
a non-recursive mutex cannot be locked more than once, even by the thread that holds the lock. This frequently becomes a problem if a program contains a number of functions, each of which must acquire a mutex, and you want to call one function as part of the implementation of another function
assume that f1() and f2() are two functions f1 and f2 each correctly lock the mutex before manipulating data but, as part of its implementation, f2 calls f1. At that point, the program deadlocks because f2 already holds the lock that f1 is trying to acquire. For this simple example, the problem is obvious. However, in complex systems with many functions that acquire and release locks, it can get very difficult to track down this kind of situation: the locking conventions are not manifest anywhere but in the source code and each caller must know which locks to acquire (or not to acquire) before calling a function. The resulting complexity can quickly get out of hand.
However, RecMutex implements a recursive mutex: • lock The lock function attempts to acquire the mutex. If the mutex is already locked by another thread, it suspends the calling thread until the mutex becomes available. If the mutex is available or is already locked by the calling thread, the call returns immediately with the mutex locked. • tryLock The tryLock function works like lock, but, instead of blocking the caller, it returns false if the mutex is locked by another thread. Otherwise, the return value is true. • unlock The unlock function unlocks the mutex. As for non-recursive mutexes, you must adhere to a few simple rules for recursive mutexes: • Do not call unlock on a mutex unless the calling thread holds the lock. • You must call unlock as many times as you called lock for the mutex to become available to another thread. (Internally, a recursive mutex is implemented with a counter that is initialized to zero. Each call to lock increments the counter and each call to unlock decrements the counter; the mutex is made available to another thread when the counter returns to zero.)
This article help for beginners as well as experinced also