RE: PATCH: Allow non-arithmetic type for pthread_t

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

This patch gets fairly ugly on Itanium, where you really want a
store-with-release semantics to implement the second write.  A barrier is
more expensive, and unnecessary here.  (Write_barrier also isn't currently
implemented there, I think, though that's easy to fix.)

This may not be performance critical enough to matter in this particular
place.  But I would generally argue for introducing regularly named
synchronization primitives that express as precisely as possible what's
needed, so that you have the best chance of implementing it efficiently on
each architecture.  I think one of those primitives should be "store with
release or write barrier semantics", which is what's needed here, and in a
number of other places.  The only required ordering is that preceding writes
shouldn't pass this one.  That can be enforced either with a release-store,
a write barrier, or a separate release barrier.  Separating out the barrier
loses performance, since some architectures combine the store and the
barrier.

All of the primitives should be explicit about the type of memory barrier
they imply, i.e. there should be variants depending on what's needed.  The
Itanium compare_and_swap currently includes only an acquire barrier, but
that's not at all apparent from the name.  I would argue that it should be
named compare_and_swap_acquire.  Theoretically there should also be

compare_and_swap_release
compare_and_swap_write
compare_and_swap_read
compare_and_swap_full

though they may not all be needed.  You can avoid all of this by just
throwing in explicit barriers next to something like a compare_and_swap.
But I don't think that gives you adequate performance.

It seems to me that ideally these synchronizition primitives should work on
standard integer types, and we need to use autoconf to find the type big
enough for something like pthread_t?

I'm not arguing that this should all be done now.  But I'm concerned that we
move in a consistent direction.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
> Sent: Tuesday, March 19, 2002 6:56 PM
> To: rittle@labs.mot.com
> Cc: java-patches@gcc.gnu.org
> Subject: Re: PATCH: Allow non-arithmetic type for pthread_t
> 
> 
> Loren James Rittle wrote:
> 
> >However, I would like to observe an outright portability bug in this
> >code with or without my proposed patch.  If sizeof (obj_addr_t) >
> >sizeof (pthread_t), then this code could blow up in various manners
> >depending upon exact architectural properties.
> >
> 
> Indeed! This patch ought to fix that. I will check it in to 
> mainline and 
> branch.
> 
> regards
> 
> Bryce.
> 
> 
>