Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Chris Thomasson
Date : Thu May 19 2005 03:56 am


> Recursively acquiring the lock is actually not less expensive because
> of that.  You cannot increment the lock count until you know that you
> are the current lock owner.
>
> In pseudo code, the Solaris recursive mutex is something like this:

[snip]

You can always use TLS to keep track of lock recursion:

http://groups.google.ca/group/comp.programming.threads/msg/011401eb846b490c?hl=en

No need for extra membars and/or atomic ops, plus you can pass a pointer to 
per-thread data to any recursion API; this can allow us to skip many calls 
into the pthread_get/setspecific API's. The simple algorithm is also generic 
enough to work well with different types of locks.

I end up using all of the per-thread information for quick debugging and an 
( unpublished ) runtime per-thread introspection/performance_counter API. 
This allows me to keep track of how many times a particular thread hit a 
fast/slow-path, on a per-lock basis. Fairly useful stuff...


You can see output like this:


thread: id8573
name: OneOfMyThreads
--------

sync_obj: id2366
name: Global_Mutex
--------
fast-path: 6520
slow-path: 1230


sync_obj: id46
name: PerQueue_Mutex
--------
fast-path: 64213
slow-path: 13




thread: id857
name: AnotherOneOfMyThreads
--------

sync_obj: id2366
name: Global_Mutex
--------
fast-path: 3520
slow-path: 230


sync_obj: id46
name: PerQueue_Mutex
--------
fast-path: 45000
slow-path: 256


sync_obj: id965
name: Polling_Mutex
--------
fast-path: 5
slow-path: 4500




;)

.