Subj : Re: Challenge: Multithreading & Synchronization To : comp.programming.threads From : doug Date : Sat May 21 2005 12:55 pm "Casper H.S. Dik" wrote in message news:428f1e45$0$64748$e4fe514c@news.xs4all.nl... > "doug" writes: > >>"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. > > > I beg to differ; we're talking about the current thread which, given > that we're trying to unlock the mutex and assuming correct application > code, we know that: > > - we're holding the lock > - no-one can change it except the current thread in the > current function. > > So the thread can inspect the lock count at its leisure, decrease it > if need be and release the lock. > > Locking is a different matter; but the only guarantee you need is > that the operations used to retrieve the owner after failing the > interlocked "acquire lock" operation will not incrrectly > return the current thread as owner. > > Casper Ah - my mistake! Sorry - I thought we were talking about lock, not unlock. My apologies. I think we agree, then. Doug .