Subj : Re: Challenge: Multithreading & Synchronization To : comp.programming.threads From : doug Date : Sat May 21 2005 11:58 am "Casper H.S. Dik" wrote in message news:428ef2d4$0$64558$e4fe514c@news.xs4all.nl... > "David Schwartz" writes: > > >> A recursive mutex will have to determine that this unlock requires the >>mutex to actually be released. This cannot easily be done without either >>an >>extra interlocked operation, per-thread data for the mutex, or hiding the >>costs elsewhere by making the lock operation complex and bizarre. > > All a recursive mutex needs is a counter; it does not need to > be interlocked as the lock is being held. > David is entirely correct, us usual. Straight to the point: "does not need to be interlocked as the lock is being held" How do you know the lock is being held? - you must either check some shared piece of state (in which case you *need* interlocked ops) - you keep that information in TLS (and so make usual case of uncontested acquire slower) - you keep that information on the stack (and so you don't actually need to use a recursive mutex) The first point is the important one. Without in interlocked operation a thread that *does not own the recursive mutex* might get the wrong answer to the question "am I already holding this?" on SMP systems. Uenal, you keep coming up with new magic to make your code work. Do as David asks - present a *complete* implementation of a recursive mutex that is not slower than a non-recursive one. (A win32 CriticalSection is not an example - it's recursive to begin with.) No magic, please - the full implementation. > > Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth. .