From owner-freebsd-threads@FreeBSD.ORG Sun Dec 23 00:08:34 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38E5416A481 for ; Sun, 23 Dec 2007 00:08:34 +0000 (UTC) (envelope-from gofdt-freebsd-threads@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 046E313C45B for ; Sun, 23 Dec 2007 00:08:33 +0000 (UTC) (envelope-from gofdt-freebsd-threads@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J6DY9-0007cO-Al for freebsd-threads@freebsd.org; Sat, 22 Dec 2007 23:14:33 +0000 Received: from cmung2217.cmu.carnet.hr ([193.198.136.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 23:14:33 +0000 Received: from ivoras by cmung2217.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Dec 2007 23:14:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-threads@freebsd.org From: Ivan Voras Date: Sun, 23 Dec 2007 00:10:53 +0100 Lines: 35 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cmung2217.cmu.carnet.hr User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) X-Enigmail-Version: 0.94.1.0 Sender: news Subject: Proper use of condition variables? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 00:08:34 -0000 Hi, I'm implementing what is basically a producer-consumer setup in which two threads communicate only by a message queue. The idea is that the consumer waits on a condition variable until something gets in the queue, then takes it out and processes it. Unfortunately the program deadlocks with the provider waiting in pthread_mutex_lock(queue_mtx) and the consumer waiting in pthread_cond_wait(queue_cv, queue_mtx). This is on RELENG_7. Am I misreading how pthread_cond_wait should behave? I thought it should release the mutex until the cv gets signaled. On the consumer side, the code looks like this: while (1) { pthread_mutex_lock(&thr->queue_mtx); if (STAILQ_EMPTY(&thr->queue)) [X] pthread_cond_wait(&thr->queue_cv, &thr->queue_mtx); job = STAILQ_FIRST(&thr->queue); STAILQ_REMOVE_HEAD(&thr->queue, linkage); pthread_mutex_unlock(&thr->queue_mtx); process(job); } On the server side, it's like this: [X] pthread_mutex_lock(&thr->queue_mtx); STAILQ_INSERT_TAIL(&thr->queue, job, linkage); pthread_mutex_unlock(&thr->queue_mtx); pthread_cond_signal(&thr->queue_cv); The two lines that deadlock are marked with [X]. From owner-freebsd-threads@FreeBSD.ORG Sun Dec 23 05:47:17 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25A7D16A417; Sun, 23 Dec 2007 05:47:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D7EBC13C45A; Sun, 23 Dec 2007 05:47:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id lBN5lFB3007275; Sun, 23 Dec 2007 00:47:15 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Sun, 23 Dec 2007 00:47:15 -0500 (EST) Date: Sun, 23 Dec 2007 00:47:15 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ivan Voras In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: Proper use of condition variables? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 05:47:17 -0000 On Sun, 23 Dec 2007, Ivan Voras wrote: > Hi, > > I'm implementing what is basically a producer-consumer setup in which > two threads communicate only by a message queue. The idea is that the > consumer waits on a condition variable until something gets in the > queue, then takes it out and processes it. Unfortunately the program > deadlocks with the provider waiting in pthread_mutex_lock(queue_mtx) and > the consumer waiting in pthread_cond_wait(queue_cv, queue_mtx). This is > on RELENG_7. Am I misreading how pthread_cond_wait should behave? I > thought it should release the mutex until the cv gets signaled. That is the way things are suppose to work. I would try libkse to see if that makes any difference. > On the consumer side, the code looks like this: > > while (1) { > pthread_mutex_lock(&thr->queue_mtx); > if (STAILQ_EMPTY(&thr->queue)) > [X] pthread_cond_wait(&thr->queue_cv, &thr->queue_mtx); > > job = STAILQ_FIRST(&thr->queue); > STAILQ_REMOVE_HEAD(&thr->queue, linkage); > > pthread_mutex_unlock(&thr->queue_mtx); > > process(job); > } > > On the server side, it's like this: > > [X] pthread_mutex_lock(&thr->queue_mtx); > STAILQ_INSERT_TAIL(&thr->queue, job, linkage); > pthread_mutex_unlock(&thr->queue_mtx); > pthread_cond_signal(&thr->queue_cv); > > > The two lines that deadlock are marked with [X]. I would put some assert()s in for the ptread_mutex_* and pthread_cond_* calls, to make sure no errors are being returned. Also, because pthread_cond_signal() is called outside the lock, it is possible for job to be NULL. This is because the server thread may get preempted after pthread_mutex_unlock() and before pthread_cond_signal() has completed. In that time, a consumer thread can run and pull the job out of the queue, process it and go back to waiting on the CV again. It is required that pthread_cond_wait() always be called with a valid mutex and with that mutex locked. It is not required for pthread_cond_signal() to have the mutex locked, but it is generally a good idea to call pthread_cond_signal() inside the locked region to avoid any possible problems like this. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Dec 24 01:47:52 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 796C716A419; Mon, 24 Dec 2007 01:47:52 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 85A1713C448; Mon, 24 Dec 2007 01:47:52 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBO1llBu031215; Mon, 24 Dec 2007 01:47:48 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476F1004.2020902@freebsd.org> Date: Mon, 24 Dec 2007 09:48:52 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@FreeBSD.org Subject: Re: Proper use of condition variables? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 01:47:52 -0000 Ivan Voras wrote: > Hi, > > I'm implementing what is basically a producer-consumer setup in which > two threads communicate only by a message queue. The idea is that the > consumer waits on a condition variable until something gets in the > queue, then takes it out and processes it. Unfortunately the program > deadlocks with the provider waiting in pthread_mutex_lock(queue_mtx) and > the consumer waiting in pthread_cond_wait(queue_cv, queue_mtx). This is > on RELENG_7. Am I misreading how pthread_cond_wait should behave? I > thought it should release the mutex until the cv gets signaled. > > On the consumer side, the code looks like this: > > while (1) { > pthread_mutex_lock(&thr->queue_mtx); > if (STAILQ_EMPTY(&thr->queue)) > [X] pthread_cond_wait(&thr->queue_cv, &thr->queue_mtx); > use : while (STAILQ_EMPTY(&thr->queue)) pthread_cond_wait(&thr->queue_cv, &thr->queue_mtx); It is possible pthread_cond_wait returned with surplus wakeup, e.g kernel signal etcs... > job = STAILQ_FIRST(&thr->queue); > STAILQ_REMOVE_HEAD(&thr->queue, linkage); > > pthread_mutex_unlock(&thr->queue_mtx); > > process(job); > } > > On the server side, it's like this: > > [X] pthread_mutex_lock(&thr->queue_mtx); > STAILQ_INSERT_TAIL(&thr->queue, job, linkage); > pthread_mutex_unlock(&thr->queue_mtx); > pthread_cond_signal(&thr->queue_cv); > > > The two lines that deadlock are marked with [X]. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 24 11:07:08 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6E916A49C for ; Mon, 24 Dec 2007 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B877A13C4F8 for ; Mon, 24 Dec 2007 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBOB77CF032096 for ; Mon, 24 Dec 2007 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBOB77ip032092 for freebsd-threads@FreeBSD.org; Mon, 24 Dec 2007 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Dec 2007 11:07:07 GMT Message-Id: <200712241107.lBOB77ip032092@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 11:07:08 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads f kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads gdb(1): using gdb with multi thread application with l o threa/118715 threads kse problem 23 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP 9 problems total.