[Bug nptl/21422] Deadlock in 2.25 pthread_cond_broadcast after process abort

[triegel at redhat dot com]

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

--- Comment #11 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Michael Krasnyk from comment #9)
> Thanks for the discussion!
> 
> The original issue is
> https://github.com/Project-OSRM/osrm-backend/issues/3911 
> Unfortunately shared condition variables may indeed end up in some
> inconsistent state and pthread_cancel will not work due to possible OOM
> SIGKILL signals.

If some of the synchronizing process can just be killed, then blocking
synchronization in general will be a problem for you.  As I mentioned earlier,
robust mutexes are different, but they had glibc implementation bugs before
glibc 2.25 and still have a bug in current Linux kernels.

If you want to avoid busy waiting when using the atomics, perhaps try combining
them with futexes to build exactly the synchronization mechanism you need.  I
don't think that futexes explicitly promise to be nonblocking, but I believe
they are in practice (eg, killing a process that's in a futex-wait call
shouldn't block subsequent futex-wake calls).

> Mainly the report is about clarification if it is an undefined behavior
> change from 2.24 to 2.25 or a regression.

I'd like to stress again that this applies to all things do potentially
blocking synchronization (eg, semaphores).  How likely you might be in practice
to run into these problems will vary, but you can't really rely on it to not
happen.

> Without robust conditional variables it will not be possible to make correct
> IPC signaling.

You can with nonblocking atomics, but I agree that this is harder.

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