Subj : Re: Challenge: Multithreading & Synchronization To : comp.programming.threads From : Casper H.S. Dik Date : Sat May 21 2005 12:40 pm "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 .