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

[Maxim Kuvyrkov <maxim@codesourcery.com>]

On 16/08/2012, at 10:20 PM, Torvald Riegel wrote:

> 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.

It is.

>  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.

This are good arguments.

> 
> 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?

The usual way how this kind of problem is solved in a free software project is that the current [arbitrary] constant causes a bottleneck on some application.  Then someone who cares about that application will investigate the problem and come to the mailing list with specific measurements and specific arguments why this constant should change.  If those arguments are reasonable and general enough, then the community will accept the change.  Then the cycle will continue.

In my opinion, really solving the heck out of a problem such as this one is not worthwhile.  I'm happy with the approximate solution that we arrived to, but I certainly encourage anyone who thinks that this is not good enough to step up and fix it for real and forever.

> 
>>> 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.)

No.

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics