Subj : Re: Optimization to Jeffrey Richter's COptex (Windows)? To : comp.programming.threads From : Joseph Seigh Date : Wed Jan 26 2005 01:36 pm On Wed, 26 Jan 2005 17:57:56 GMT, Luke Elliott wrote: > Joseph Seigh wrote: >> 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. >> > > 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. > The dispatcher takes care of memory visibility if it switches a threads to a different processor. Context switching is transparent to the thread. Cache has nothing to do with anything here. Cache is transparent and your program cannot detect whether or not cache is present. The memory model is the same in either case. Where are people getting this idea that cache affects memory visibility? -- Joe Seigh .