Subj : Re: CMPXCHG timing To : comp.programming.threads From : David Schwartz Date : Fri Apr 01 2005 04:47 pm "Michael Pryhodko" wrote in message news:1112400242.988975.227840@o13g2000cwo.googlegroups.com... > I DO NOT WANT ATOMIC BEHAVIOR! Please, read carefully more formal > description of algorithm I posted. The whole idea of it was "we do not > need LOCK to do lock". > Main "feature" of algorithm was that ONLY i-th processor could ever > write unique value Pi into lock variable, but with this stupid > implementation of CMPXCHG any processor that tries to enter locked lock > writes Pi of lock owner every CMPXCHG call. This spoils whole idea. > I do not understand why Intel decided to implement CMPXCHG this way, > but from all I learned so far I do not know any good "excuse" for that. I'm utterly baffled how your algorithm was supposed to work. What keeps all the processors from reading the zero value and all deciding to exchange it with the Pi value? Since the operation is not atomic, it's equivalent to 'read, compare, possibly store'. What stops all the processors from reading at the same time, comparing at the same time, and then storing in succession, each thinking it wrote the unique value? Each succeeding with its compare/exchange. If you're waiting for all threads to finish anyway, how does the extra write hurt you? You wait for all threads to finish and read the value of the lock. So what's the problem? And why are you doing all this anyway when it's clear that a simple LOCK prefix will 100% work. DS .