From owner-freebsd-stable@FreeBSD.ORG Wed May 14 18:50:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E516106567F for ; Wed, 14 May 2008 18:50:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id D73558FC22 for ; Wed, 14 May 2008 18:50:30 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1JwM3Z-000KjA-Mq; Wed, 14 May 2008 21:50:29 +0300 Message-ID: <482B3475.6060803@icyb.net.ua> Date: Wed, 14 May 2008 21:50:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.12 (X11/20080320) MIME-Version: 1.0 To: freebsd-threads@freebsd.org, freebsd-stable@freebsd.org References: <482B0297.2050300@icyb.net.ua> In-Reply-To: <482B0297.2050300@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: thread scheduling at mutex unlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 18:50:31 -0000 on 14/05/2008 18:17 Andriy Gapon said the following: > I am trying the small attached program on FreeBSD 6.3 (amd64, > SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads > library and on both it produces "BROKEN" message. > > I compile this program as follows: > cc sched_test.c -o sched_test -pthread > > I believe that the behavior I observe is broken because: if thread #1 > releases a mutex and then tries to re-acquire it while thread #2 was > already blocked waiting on that mutex, then thread #1 should be "queued" > after thread #2 in mutex waiter's list. > > Is there any option (thread scheduler, etc) that I could try to achieve > "good" behavior? > > P.S. I understand that all this is subject to (thread) scheduler policy, > but I think that what I expect is more reasonable, at least it is more > reasonable for my application. > > Daniel Eischen has just kindly notified me that the code (as an attachment) didn't make it to the list, so here it is inline. #include #include #include #include pthread_mutex_t mutex; int count = 0; static void * thrfunc(void * arg) { while (1) { pthread_mutex_lock(&mutex); count++; if (count > 10) { fprintf(stderr, "you have a BROKEN thread scheduler!!!\n"); exit(1); } sleep(1); pthread_mutex_unlock(&mutex); } } int main(void) { pthread_t thr; #if 0 pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE_NP); pthread_mutex_init(&mutex, &attr); #else pthread_mutex_init(&mutex, NULL); #endif pthread_create(&thr, NULL, thrfunc, NULL); sleep(2); pthread_mutex_lock(&mutex); count = 0; printf("you have good thread scheduler\n"); pthread_mutex_unlock(&mutex); return 0; } -- Andriy Gapon