Date: Mon, 19 Apr 2021 07:24:39 +0000 From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 254995] pthread_cond_timedwait() returns EDEADLK Message-ID: <bug-254995-13406-al5hMJoyUN@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254995-13406@https.bugs.freebsd.org/bugzilla/> References: <bug-254995-13406@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254995 --- Comment #2 from nkoch@demig.de --- Yes, that is the thread that dead locks. I do not stop the process (to my knowledge). I am having a simple producer-consumer queue with 2 conds not_empty and not_full and one mutex (process local, PTHREAD_MUTEX_ERRORCHECK, PTHREAD_PRIO_INHERIT). EDEADLK comes from the consumer waiting for anything with timeout. The timeout is 100ms only as there is a regular keep alive check of this thread. The producer never waits. So its basically this: consumer thread: for(;;) { pthread_mutex_lock() if queue_empty() phtread_cond_timedwait() // <-- EDEADLK once in a month if !queue_empty() { read from queue pthread_cond_signal(not_full) } pthread_mutex_unlock() signal_alive() do_something() } producer thread: ... pthread_mutex_lock() if !queue_full() { write to queue pthread_cond_signal(not_empty) } pthread_mutex_unlock() ... BTW, there are about 32 threads with different realtime priorities and the programs very often forks/execs other programs. I have never seen this under FreeBSD 10.3 and 9.1 with the same software, but that may of course mean that there were other effects I did not see so far. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254995-13406-al5hMJoyUN>