[Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

["malteskarupke at fastmail dot fm" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25847

--- Comment #50 from Malte Skarupke <malteskarupke at fastmail dot fm> ---
I sent a new version of my patch series:
https://sourceware.org/pipermail/libc-alpha/2022-October/142562.html

It fixes the issue where the first patch applied on its own didn't work. (it
had a bug that was fixed by the third patch in the series) I also rebased the
patch to work on top of release/2.36/master.

I'm pretty confident that these fix the issue, but they do still need review. I
am also still thinking of doing the following two things:
1. Properly review Frank Barrus' patch, because from the little I looked at, I
like it and it might be a better solution than the patch I submitted here.
2. Maybe submit a patch that just allows more spurious wakeups. The original
problem was that if a waiter takes too long to wake, and the group switched
twice, it could steal a signal from a later group and a waiter from a later
group would go back to sleep. And then the code that was supposed to handle
that caused this bug. But my current thinking is "what if the thread whose
signal got stolen just doesn't go back to sleep?" Meaning you'd be fine with
slightly more spurious wakeups in edge cases. I think it would simplify a lot.

Still don't have a lot of time to work on this though. So I first just wanted
to get my patch back into a good condition. I think the first patch in the
series is a low-risk fix, after it has been reviewed and tested a bit more. It
doesn't change much and I actually did the work of verifying it in TLA+.

-- 
You are receiving this mail because:
You are on the CC list for the bug.