Re: [PATCH] Unify pthread_spin_[try]lock implementations.

[Roland McGrath <roland@hack.frob.com>]

> The tile architecture is unlikely to use this generic version no matter
> what; see http://sourceware.org/ml/libc-ports/2012-07/msg00030.html for the
> details, but the primary point is that in a mesh-based architecture it's a
> bad idea to ever end up in a situation where all the cores can be spinning
> issues loads or cmpxchg as fast as they can, so some kind of backoff is
> necessary.

I had read that before but only noticed the explanation that the plain
reads were bad.  (Hence in my suggestion you'd share the code but with a
#define that means the loop of plain reads would be elided entirely at
compile time by constant folding.)  What kind of "backoff" do you mean?
It's probably appropriate on every machine to use "atomic_delay ();" inside
such loops.


Thanks,
Roland