Subj : Re: Optimization to Jeffrey Richter's COptex (Windows)? To : comp.programming.threads From : Luke Elliott Date : Wed Jan 26 2005 09:22 pm Joseph Seigh wrote: > 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? > > Well I'm not sure what you're getting at now - all I was saying is that if the shared thread id value isn't set using an interlocked op, then another thread running on a different processor could see a different value. Anyway, I've run the stress app on a dual CPU machine and it appears ok. Going to run with it and hope for the best! Thanks Luke. .