RE: [committed] Add locking semaphore to sysdep/pa/locks.h

["Boehm, Hans" <hans dot boehm at hp dot com>]

I think that moving this into the compiler, and eventually the language
spec is clearly the right direction.

But I personally don't think that the current Itanium-ABI-derived gcc
primitives give quite enough control over ordering constraints.
(Although I believe this was a recent gcc addition, I think the
interface is actually fairly old by now.)  In particular,
__sync_bool_compare_and_swap seems to always include a full memory
fence.  That means, if it's used to implement a lock acquisition, memory
operations must not only be prevented from moving out of the critical
section, as expected, but they must also not move into the critical
section, which is generally over-kill.  On X86, this is "free", since
the cmpxchg instruction includes the fence anyway.  On Itanium and
Power, I believe the relative cost can be significant, since the
hardware has weaker (and sometimes much cheaper) built-in support.

Aside from platform support issues, it wouldn't be a terrible choice to
use it.  But it would preclude some moderately significant future
performance enhancements, and probably slow down the PowerPC port.

We're working on an interface that will hopefully make it into the next
C++ standard.  If so, that's clearly the right one to use long term.
But I think it makes sense to pin that one down a bit better before
lobbying for any changes/additions to the gcc intrinsics.

There is some more detailed discussion of the need for memory fences in
locks, with a bit of data, in

http://www.hpl.hp.com/techreports/2005/HPL-2005-217.html

Hans

> -----Original Message-----
> From: John David Anglin [mailto:dave@hiauly1.hia.nrc.ca] 
> Sent: Wednesday, January 04, 2006 12:56 PM
> To: tromey@redhat.com
> Cc: Boehm, Hans; java@gcc.gnu.org
> Subject: Re: [committed] Add locking semaphore to sysdep/pa/locks.h
> 
> 
> > I'm curious to know how this compares to using the gcc 
> synchronization 
> > builtins.
> 
> These aren't supported on the PA.
> 
> Dave
> -- 
> J. David Anglin                                  
> dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 
> 990-0752 (FAX: 952-6602)
>