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