This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]