Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : David Schwartz
Date : Thu Aug 25 2005 12:26 pm


"John Hickin" <hickin@nortelnetworks.com> wrote in message 
news:del1q8$6f2$1@zcars129.ca.nortel.com...

> "David Schwartz" <davids@webmaster.com> wrote in message
> news:del00d$vps$1@nntp.webmaster.com...

>>     This is a disaster on a machine with more than 2 CPUs or
>> hyper-threading. In the more than 2 CPUs case, two CPUs in the 'while'
>> loop
>> will totally saturate the FSB, causing the CPU that needs to release the
>> lock to be unable to do so. In the hyper-threaded case, the virtual CPU 
>> in
>> the while loop will steal resources from the thread that's doing useful
>> work.

> So I was correct about falling into a trap :-)

    Yeah. You can fix the HT problem by putting a 'rep nop' in the 'while' 
loop. You can fix the 3+ CPUs problem by using a read-only instruction to 
spin on and calling the locked function only if the read suggests the 
compare/swap will succeed.

    However, there are more traps you can fall into. ;)

    DS

.