Subj : Re: Optimization to Jeffrey Richter's COptex (Windows)? To : comp.programming.threads From : Luke Elliott Date : Wed Jan 26 2005 05:57 pm Joseph Seigh wrote: > On Wed, 26 Jan 2005 15:33:00 GMT, Luke Elliott > wrote: > >> Joseph Seigh wrote: >> >>>> >>> I'm not sure what Richter is using the thread id for since checking for >>> it is a debug option. Most of the stuff out of Redmond is rather >>> strange >>> and odd. I wouldn't look to it for good examples of doing anything. >>> >>> Most conventional solutions require the lock owner id to be atomic. >>> Setting >>> it and unsetting it is done while holding the lock. Unlocking code >>> checks >>> the owner id without a lock since the only way it could match the >>> current thread >>> it is if it owned the lock. >>> >> >> Yeah that's what I was thinking (for single processor). >> >> What I was thinking could happen in the SMP case was something like: >> >> 1. Thread id 1234 runs on processor 1 >> * Acquires lock >> * Releases lock >> >> 2. Thread id 5678 runs on processor 2 >> * Acquires lock >> >> 3. Thread id 1234 runs on processor 3 >> * Could value of thread id in COptex could still be 1234 from [1], >> confusing the recurse count? This thread thinks it owns the lock but >> doesn't. >> >> Except that (presumably) can't happen because the interlocked ops from >> acquire in [2] and in the first step of [3] will cause the processor >> caches to be coherent. >> > > No. If a thread releases the lock, it sets the owning thread id to zero. > If it doesn't set the thread id again then it can only see zero or the > thread id of another thread. There's no reason to use InterlockedExchange > to set the thread id since it's atomic anyway. Also the spinning technique > in TryEnter is inefficient. > > Joe Seigh > > The case that was bothering me was if the first thread is then later scheduled on a different processor - could there be an issue with cache coherency with respect to the thread id value? But presumably the interlocked op after setting thread id to 0 in the release code avoids that problem. .