This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
pthread_cond_t in shared memory
- From: Dan Melnic <dmm at fb dot com>
- To: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Wed, 17 Apr 2019 21:28:41 +0000
- Subject: pthread_cond_t in shared memory
Hi,
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 ?
Thanks,
Dan