This is the mail archive of the glibc-bugs@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]

[Bug nptl/10418] pthread_mutex_unlock may use acquire rather than release barriers


------- Additional Comments From cfriesen at nortel dot com  2009-07-27 17:03 -------
I'm confused.  The change you've submitted is exactly opposite to what I
proposed.  The new code now has release semantics on the lock, and acquire
semantics on the unlock, which is backwards from my understanding of what they
should be.

The comment in the patch is "All commits should have happened before the mutex
lock is taken. Therefore use the _rel variant of the cmpxchg atomic op."

We're trying to ensure that writes which happen while holding the lock on one
cpu are visible to another cpu which acquires the lock.  This means that the
barrier must come before the atomic operation which releases the lock, and after
the atomic operation which acquires the lock.  I think the correct comment
should be "All commits should have happened before the mutex lock is freed,
therefore use the _rel variant of the cmpxchg atomic op."



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://sourceware.org/bugzilla/show_bug.cgi?id=10418

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


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