summaryrefslogtreecommitdiff
path: root/src/thread/pthread_mutexattr_destroy.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2018-09-14 10:47:16 -0400
committerRich Felker <dalias@aerifal.cx>2018-09-14 10:47:16 -0400
commit12817793301398241b6cb00c740f0d3ca41076e9 (patch)
treeed95d63dbd53e2a60dd28dcabb9b245e54d935bd /src/thread/pthread_mutexattr_destroy.c
parent7d7f44253f2d8cfd0a7adf9f918d88aa24d4e012 (diff)
downloadmusl-12817793301398241b6cb00c740f0d3ca41076e9.tar.gz
fix broken atomic store on powerpc[64]
in our memory model, all atomics are supposed to be full barriers; stores are not release-only. this is important because store is used as an unlock operation in places where it needs to acquire the waiter count to determine if a futex wake is needed. at least in the malloc-internal locks, but possibly elsewhere, soft deadlocks from missing futex wake (breakable by poking the threads to restart the syscall, e.g. by attaching a tracer) were reported to occur. once the malloc lock is replaced with Jens Gustedt's new lock implementation (see commit 47d0bcd4762f223364e5b58d5a381aaa0cbd7c38), malloc will not be affected by the issue, but it's not clear that other uses won't be. reducing the strength of the ordering properties required from a_store would require a thorough analysis of how it's used. to fix the problem, I'm removing the powerpc[64]-specific a_store definition; now, the top-level atomic.h will implement a_store using a_barrier on both sides of the store. it's not clear to me yet whether there might be issues with the other atomics. it's possible that a_post_llsc needs to be replaced with a full barrier to guarantee the formal semanics we want, but either way I think the difference is unlikely to impact the way we use them.
Diffstat (limited to 'src/thread/pthread_mutexattr_destroy.c')
0 files changed, 0 insertions, 0 deletions