pthread_cond_t in shared memory

[Florian Weimer]

* Dan Melnic:

> I have a question about pthread_cond_t in a shared memory area created
> via shm_open.
> I have a process that does a pthread_cond_broadcast (or pthread_cond_signal).
> If the process is stopped (just Ctrl-C) after __condvar_acquire_lock
> but before __condvar_release_lock, then next time the process is
> started, the pthread_cond_broadcast will wait forever here (the shm
> area is not removed via shm_unlink):
>
> #0 0x00007ffff70d1e26 in futex_wait (private=<optimized out>,
> expected=<optimized out>, futex_word=0x7ffff7fec020) at
> ../sysdeps/unix/sysv/linux/futex-internal.h:61
> #1 futex_wait_simple (private=<optimized out>, expected=<optimized
> out>, futex_word=0x7ffff7fec020) at
> ../sysdeps/nptl/futex-internal.h:135
> #2 __condvar_acquire_lock (private=<optimized out>,
> cond=0x7ffff7fec000) at pthread_cond_common.c:280
> #3 __pthread_cond_broadcast (cond=0x7ffff7fec000) at
> pthread_cond_broadcast.c:48
> #4 0x0000000000402b2a in main (argc=<optimized out>, argv=<optimized
> out>) at experimental/dmm/cond.c:82
>
> Is this a known issue and if it is, is there a way to avoid what it
> looks like a deadlock ?

The glibc implementation of POSIX condition variables is not robust.
If one of the participating threads dies, such hangs can be the
result.  (POSIX does not require condition variables to be robust.)