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