This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/10418] pthread_mutex_unlock may use acquire rather than release barriers
- From: "cfriesen at nortel dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 27 Jul 2009 17:03:30 -0000
- Subject: [Bug nptl/10418] pthread_mutex_unlock may use acquire rather than release barriers
- References: <20090720164254.10418.cfriesen@nortel.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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.