This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix sem_post race (bug 14532)


On Wed, 2012-09-12 at 15:19 +0000, Joseph S. Myers wrote:
> On Tue, 11 Sep 2012, Torvald Riegel wrote:
> 
> > >    atomic_full_barrier ();
> > 
> > Why do we have the full barrier after the rel barrier?  Is it necessary?

Attached is a draft patch that documents the synchronization used to
build the semaphore.  Please comment whether that is useful for
everyone, or whether we need more details, a different format, or
whatever.  Perhaps we can use the semaphore as a template / example for
how concurrent code should be documented in glibc.

I tried to keep this short enough while still pointing out the
relationships with related code pieces.  I also used the C11/C++11
memory model terminology, even though glibc's sync functions are named
slightly differently.

Also, atomic operations without an _acq or _rel suffix seem to always
default to _acq.  Is this a guarantee (and thus should be documented)?
I'm wondering whether it would be better to use an explicit suffix in
the long-term.

> I wouldn't say we have it after the rel barrier.  Apart from the rel 
> barrier being a barrier before the compare-and-exchange operation, so the 
> barriers are separated by that operation, the formatting of the code 
> implies that the positioning of the barrier is logically "before the code 
> to wake a waiter" rather than "after the code to update the semaphore 
> value", and so the code to wake a waiter is where you should look for the 
> reason for this barrier.

I got confused because I didn't see a counterpart to the full fence
anywhere; so far, I assumed that futex_wait does not imply a full membar
before the read from the futex variable.  But the existing code relies
on this; is this guarantee commonly known to be true on all
architectures (e.g., is a syscall always like a full membar,
everywhere)?


Torvald

Attachment: patch1
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]