On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++ <libstd...@gcc.gnu.org> wrote: > > This issue was observed as a deadloack in > 29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is > "laundered" (e.g. type T* does not suffice as a waitable address for the > platform's native waiting primitive), the address waited is that of the > _M_ver member of __waiter_pool_base, so several threads may wait on the > same address for unrelated atomic<T>'s. As noted in the PR, the > implementation correctly exits the wait for the thread who's data > changed, but not for any other threads waiting on the same address. > > As noted in the PR the __waiter::_M_do_wait_v member was correctly exiting > but the other waiters were not reloaded the value of _M_ver before > re-entering the wait. > > Moving the spin call inside the loop accomplishes this, and is > consistent with the predicate accepting version of __waiter::_M_do_wait.
There is a change to the memory order in _S_do_spin_v which is not described in the commit msg or the changelog. Is that unintentional? (Aside: why do we even have _S_do_spin_v, it's called in exactly one place, so could just be inlined into _M_do_spin_v, couldn't it?)
