From owner-freebsd-threads@FreeBSD.ORG Mon Mar 16 08:46:10 2009 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 75E1E1065680 for ; Mon, 16 Mar 2009 08:46:10 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from www61.your-server.de (www61.your-server.de [213.133.104.61]) by mx1.freebsd.org (Postfix) with ESMTP id 328BA8FC16 for ; Mon, 16 Mar 2009 08:46:10 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from [217.7.243.216] (helo=firewall.demig.intra) by www61.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lj8DJ-0000li-Hw for freebsd-threads@freebsd.org; Mon, 16 Mar 2009 09:30:25 +0100 Received: from [192.168.148.72] (ws-pr-3.demig.intra [192.168.148.72]) by firewall.demig.intra (8.14.3/8.14.0) with ESMTP id n2G8U0eF029893 for ; Mon, 16 Mar 2009 09:30:00 +0100 (CET) (envelope-from nkoch@demig.de) Message-ID: <49BE0E07.50908@demig.de> Date: Mon, 16 Mar 2009 08:29:59 +0000 From: Norbert Koch Organization: demig Prozessautomatisierung GmbH User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 192.168.148.235 X-Authenticated-Sender: webmaster@demig.de X-Virus-Scanned: Clear (ClamAV 0.94.1/9111/Mon Mar 16 03:12:07 2009) Subject: 'pthread_mutex_unlock() BUG in libc_r? 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, 16 Mar 2009 08:46:10 -0000 Hello, first of all, I know that libc_r is an ancient and no more supported library. But what I found looks like such a huge bug that I would like to hear a different opinion about that. Because, may be I am totally wrong with that. (Btw. I am doing this under FreeBSD 4.11 but libc_r looks the same under 7.1) I am having two threads A (low priority) and B (high priority). This is the pseudo code: Thread A: forever { sleep_some_time() call common_func() set global ponter P to NULL } Thread B: forever { sleep_some_time() set global pointer P to not NULL call common_func() assert P is not NULL } common_func() { pthread_lock_mutex(M) do something completely_unrelated pthread_mutex_unlock(M) } Without calling common_func() all is ok. With common_func the assertion fails from time to time. The problem I found is in pthread_mutex_unlock(). As far as I understand the code, the next thread waiting on the mutex is made runnable, but there is no call of the scheduler! This means, that the lower priority thread will continue running until blocking itself or being switched away by running out of time. I see the same (wrong?) code in pthread_cond_signal() and pthread_cond_broadcast(). So, could anyone please enlighten me if I am totally wrong here or if there is perhaps some weird hidden aspect in the posix standard I missed? If I found a bug here, what about libthr/libpthread? Are they behaving correctly? Best regards, Norbert Koch From owner-freebsd-threads@FreeBSD.ORG Mon Mar 16 09:32:29 2009 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 1C725106566B for ; Mon, 16 Mar 2009 09:32:29 +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 D240D8FC14 for ; Mon, 16 Mar 2009 09:32:28 +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.3/8.14.3/NETPLEX) with ESMTP id n2G9EQxF022385; Mon, 16 Mar 2009 05:14:27 -0400 (EDT) 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]); Mon, 16 Mar 2009 05:14:27 -0400 (EDT) Date: Mon, 16 Mar 2009 05:14:26 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Norbert Koch In-Reply-To: <49BE0E07.50908@demig.de> Message-ID: References: <49BE0E07.50908@demig.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: 'pthread_mutex_unlock() BUG in libc_r? 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: Mon, 16 Mar 2009 09:32:29 -0000 On Mon, 16 Mar 2009, Norbert Koch wrote: > Hello, > > first of all, I know that libc_r is an ancient and > no more supported library. > But what I found looks like such a huge bug that > I would like to hear a different opinion about > that. Because, may be I am totally wrong with that. > (Btw. I am doing this under FreeBSD 4.11 but libc_r > looks the same under 7.1) > > I am having two threads A (low priority) and B (high priority). > This is the pseudo code: > > Thread A: > forever { > sleep_some_time() > call common_func() > set global ponter P to NULL > } > > Thread B: > forever { > sleep_some_time() > set global pointer P to not NULL > call common_func() > assert P is not NULL > } > > common_func() > { > pthread_lock_mutex(M) > do something completely_unrelated > pthread_mutex_unlock(M) > } There is no guarantee that pthread_mutex_unlock() (or other unlocks of synchronization types) are preemption points. Also, you cannot assume that the run time for each thread is the same. The threads are started at separate times, and there may even be a scheduling preemption point between the two successful calls to pthread_create() causing one thread to start before the next thread is created. There is no guarantee that sleep_some_time() ends exactly the same for both threads. In order for this to work, you need both threads A and B to block on a synchronization variable (mutex, CV, etc) and to have the main thread (or another thread) wake them up after ensuring that they both are waiting. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Mar 16 11:07:04 2009 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 507981065691 for ; Mon, 16 Mar 2009 11:07:04 +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 344C58FC23 for ; Mon, 16 Mar 2009 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2GB749d043420 for ; Mon, 16 Mar 2009 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2GB73hS043416 for freebsd-threads@FreeBSD.org; Mon, 16 Mar 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Mar 2009 11:07:03 GMT Message-Id: <200903161107.n2GB73hS043416@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, 16 Mar 2009 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 37 problems total.