diff options
author | Jonathan Wakely <jwakely@redhat.com> | 2022-07-28 16:15:58 +0100 |
---|---|---|
committer | Jonathan Wakely <jwakely@redhat.com> | 2022-08-04 13:09:39 +0100 |
commit | af98cb88eb4be6a1668ddf966e975149bf8610b1 (patch) | |
tree | 71a6acd698921652824faea283b8d2108a67de04 /libstdc++-v3/include/std/version | |
parent | 075683767abe15b936ad41792da6ee71e9eda449 (diff) | |
download | gcc-af98cb88eb4be6a1668ddf966e975149bf8610b1.zip gcc-af98cb88eb4be6a1668ddf966e975149bf8610b1.tar.gz gcc-af98cb88eb4be6a1668ddf966e975149bf8610b1.tar.bz2 |
libstdc++: Unblock atomic wait on non-futex platforms [PR106183]
When using a mutex and condition variable, the notifying thread needs to
increment _M_ver while holding the mutex lock, and the waiting thread
needs to re-check after locking the mutex. This avoids a missed
notification as described in the PR.
By moving the increment of _M_ver to the base _M_notify we can make the
use of the mutex local to the use of the condition variable, and
simplify the code a little. We can use a relaxed store because the mutex
already provides sequential consistency. Also we don't need to check
whether __addr == &_M_ver because we know that's always true for
platforms that use a condition variable, and so we also know that we
always need to use notify_all() not notify_one().
Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/106183
* include/bits/atomic_wait.h (__waiter_pool_base::_M_notify):
Move increment of _M_ver here.
[!_GLIBCXX_HAVE_PLATFORM_WAIT]: Lock mutex around increment.
Use relaxed memory order and always notify all waiters.
(__waiter_base::_M_do_wait) [!_GLIBCXX_HAVE_PLATFORM_WAIT]:
Check value again after locking mutex.
(__waiter_base::_M_notify): Remove increment of _M_ver.
Diffstat (limited to 'libstdc++-v3/include/std/version')
0 files changed, 0 insertions, 0 deletions