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

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2012-08-15 at 15:16 +1200, Maxim Kuvyrkov wrote:
> On 26/07/2012, at 6:13 AM, Roland McGrath wrote: 
> > /* Machine-dependent rationale about the selection of this value.  */
> > #define SPIN_LOCK_READS_BETWEEN_CMPXCHG 1000

This looks like an arbitrary choice.  I don't want to complain about
this patch (whose goal is to just unify similar code), but let me use it
as an example.
Elsewhere in the thread, you (IIRC) mentioned that the assumption is
that a CAS is 100x slower than a load. IMO, this is a flawed assumption.
First, this has more dimensions than one instruction being slower than
another one: cache architecture, what other threads are doing and where
in the cache hierarchy/graph they are, the CAS HW implementation, etc.
Second, it's not really about the slow-down for the current thread when
executing a CAS; it's about what the CAS might do in terms of caching
and the latency at which you detect a free lock on ARM, as Andrew Haley
pointed out.  Third, not all machines in an architecture are similar; a
P4 cmpxchg performs much differently to a cmpxchg on a recent x86 CPU.
Fourth, there's no test for this assumption.

So, we will have to make such assumptions, but how do we make sure that
they are reasonable, and remain reasonable over time?  If we don't,
these will bit-rot, and performance might degrade over time (assuming
that the assumptions were initially correct, which might be hard in the
first place).  Is there a plan for this yet, or discussion about this?

> > while Teil will use -1.

Is there a plan to include a back-off component in this generic spin
lock?  (-1 would spin forever, but not do back-off.)


Torvald