Re: [9fans] _xinc vs ainc

[Bakul Shah <bakul@bitblocks.com>]

On Sat, 07 May 2011 18:47:54 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > Just guessing. May be the new code allows more concurrency? If the
> > value is not in the processor cache, will the old code block other
> > processors for much longer? The new code forces caching with the first
> > read so may be high likelyhood cmpxchg will finish faster. I haven't
> > studied x86 cache behavior so this guess could be completely wrong.
> > Suggest asking on comp.arch where people like Andy Glew can give you a
> > definitive answer.
>
> according to intel, this is a myth.  search for "myth" in this page.
>
> http://software.intel.com/en-us/articles/implementing-scalable-atomic-locks-f
> or-multi-core-intel-em64t-and-ia32-architectures/
>
> and this stands to reason, since both techniques revolve around a
> LOCK'd instruction, thus invoking the x86 architectural MESI(f)
> protocol.
>
> the difference, and my main point is that the loop in ainc means
> that it is not a wait-free algorithm.  this is not only sub optimal,
> but also could lead to incorrect behavior.

I think a more likely possibility for the change is to have a
*copy* of what was incremented. lock incl 0(ax) won't tell you
what the value was when it was incremented.

But I don't see how the change will lead to an incorrect behavior.