diff options
author | Torvald Riegel <triegel@redhat.com> | 2015-07-14 21:58:34 +0200 |
---|---|---|
committer | Torvald Riegel <triegel@redhat.com> | 2015-12-23 18:44:53 +0100 |
commit | 389fdf78b2e606387ce9d51f29e5c0a22ad9ad2a (patch) | |
tree | 3c665e20903d53ded06618a794b10d0d28292cc9 /ChangeLog.15 | |
parent | 7962541a32eff5597bc4207e781cfac8d1bb0d87 (diff) | |
download | glibc-389fdf78b2e606387ce9d51f29e5c0a22ad9ad2a.tar.gz glibc-389fdf78b2e606387ce9d51f29e5c0a22ad9ad2a.tar.xz glibc-389fdf78b2e606387ce9d51f29e5c0a22ad9ad2a.zip |
Do not violate mutex destruction requirements.
POSIX and C++11 require that a thread can destroy a mutex if no other thread owns the mutex, is blocked on the mutex, or will try to acquire it in the future. After destroying the mutex, it can reuse or unmap the underlying memory. Thus, we must not access a mutex' memory after releasing it. Currently, we can load the private flag after releasing the mutex, which is fixed by this patch. See https://sourceware.org/bugzilla/show_bug.cgi?id=13690 for more background. We need to call futex_wake on the lock after releasing it, however. This is by design, and can lead to spurious wake-ups on unrelated futex words (e.g., when the mutex memory is reused for another mutex). This behavior is documented in the glibc-internal futex API and in recent drafts of the Linux kernel's futex documentation (see the draft_futex branch of git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git).
Diffstat (limited to 'ChangeLog.15')
0 files changed, 0 insertions, 0 deletions