Subj : Re: Optimization to Jeffrey Richter's COptex (Windows)? To : comp.programming.threads From : Joseph Seigh Date : Wed Jan 26 2005 12:31 pm 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 -- Joe Seigh .