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