[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 #24 from Malte Skarupke <malteskarupke at fastmail dot fm> ---
(In reply to Torvald Riegel from comment #23)
> Consider the case where a signal is stolen by thread A from a group 1 that
> is then fully signaled according to the group size, and then another thread
> B tries to quiesce and switch group 1.  The internal lock is held by B,
> which waits for a waiter W whose signal has been stolen by A.  W can't make
> progress because A has "its" signal.  And A waits for B if one adds the
> empty critical section, which is how I think this can deadlock.
> 
> > The mitigation patch
> > will call these functions.
> 
> It does, but after giving back the stolen signal (or at least trying to do
> so, incorrectly).

That makes sense, and it would mean that the mitigation patch should be good.

So if stealing happens, a waiter is blocked. And that causes a signaler to
block because it can't close the group. And because of that, I couldn't undo
the stealing by signaling, because two threads can't signal at the same time
because they have to hold the internal mutex.

Instead we have to do the partial signal that we do right now. But that one
fails if stealing didn't happen. Because then we get into a weird state where
g_size is incorrect because we can't change g_size without taking the internal
mutex.

This means we have to do something different depending on whether stealing
happened or didn't happen. But we only have this code to begin with because we
can't tell one from the other.

Which means the mitigation patch might be the only way to do this properly: Do
the partial signal in case stealing happens, and then in case stealing didn't
happen do a broadcast to reset the state. And replacing the broadcast with a
signal will be difficult because signaling doesn't reset the state of the
condition variable, and therefore can't get us out of the weird state in case
stealing didn't happen.

I personally think this is unsatisfying. It's very complex, even if we can find
a way to do this correctly. So I won't attempt to work in this direction again,
and I'll instead try to clean up the patch that makes stealing impossible,
which reduces complexity.

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