Re: spinlocks: generalizing "non-locking test" - Mailing list pgsql-hackers

From Neil Conway
Subject Re: spinlocks: generalizing "non-locking test"
Date
Msg-id 1098062337.22986.111.camel@localhost.localdomain
Whole thread Raw
In response to Re: spinlocks: generalizing "non-locking test"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: spinlocks: generalizing "non-locking test"
List pgsql-hackers
On Mon, 2004-10-18 at 04:13, Tom Lane wrote:
> Do you have any actual evidence for that opinion?  ISTM this is
> dependent on a large set of assumptions about the CPU's bus behavior,
> boiling down to the conclusion that an extra conditional branch is
> cheaper than a locked bus cycle.

I think the conditional branch is effectively free: we're spinning in a
busy-wait loop, so we're effectively throwing away cycles until the lock
is free anyway. The important things are: (a) we interfere as little as
possible with concurrent system activity while spinning (b) we notice
promptly that the lock is free. ISTM that doing a non-locking test
before the locking test achieves those two conditions.

> (For that matter, I'm not that thrilled about it even for the Intel
> chips, since the extra test is certainly 100% wasted cycles on any
> single-CPU machine, or indeed anywhere that the lock is not contended
> for.)

Yes, but the proper fix for this is not to spin at all on UP machines; I
have a grungy patch to do this that I will clean up and send in for 8.1.

> >      if (*lock == 0)
> >          TAS(lock);
> 
> This will certainly not work on HPPA, and it really shouldn't assume
> that zero is the non-locked state, and what happened to testing the
> TAS result?

Erm, perhaps I should have emphasized that that was pseudo-code :) A
more realistic implementation would be:

#define TAS_INNER_LOOP(lock) (S_LOCK_FREE(lock) ? TAS(lock) : 1)

-Neil




pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: Open Items
Next
From: Neil Conway
Date:
Subject: Re: additional GCC warnings