From owner-freebsd-stable@FreeBSD.ORG Thu May 15 05:56:59 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 1EEA81065673; Thu, 15 May 2008 05:56:59 +0000 (UTC) (envelope-from b.j.casavant@ieee.org) Received: from yeppers.tdkt.org (skyline.tdkt.org [209.98.211.67]) by mx1.freebsd.org (Postfix) with ESMTP id BBA2A8FC1B; Thu, 15 May 2008 05:56:58 +0000 (UTC) (envelope-from b.j.casavant@ieee.org) Received: from [192.168.0.29] (c-98-240-155-201.hsd1.mn.comcast.net [98.240.155.201]) (authenticated bits=0) by yeppers.tdkt.org (8.12.11/8.12.11/erikj-OpenBSD) with ESMTP id m4F5GKo8015883; Thu, 15 May 2008 00:16:21 -0500 (CDT) Date: Thu, 15 May 2008 00:16:14 -0500 (CDT) From: Brent Casavant X-X-Sender: bcasavan@ella.local To: Andriy Gapon In-Reply-To: <482B0297.2050300@icyb.net.ua> Message-ID: References: <482B0297.2050300@icyb.net.ua> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: "Angeltread Software Organization" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: Re: thread scheduling at mutex unlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brent Casavant List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 05:56:59 -0000 On Wed, 14 May 2008, Andriy Gapon wrote: > 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. The behavior of scheduling with respect to mutex contention (apart from pthread_mutexattr_setprotocol()) is not specified by POSIX, to the best of my knowledge, and thus is left to the discretion of the implementation. > Is there any option (thread scheduler, etc) that I could try to achieve > "good" behavior? No portable mechanism, and not any mechanism in the operating systems with which I am familiar. That said, as the behavior is not specified by POSIX, there would be nothing preventing an implementation from providing this as an optional behavior through a custom pthread_mutexattr_???_np() interface. > 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. As other responders have indicated, the behavior you desire is as unoptimal as possible for the general case. If your application would truly benefit from this sort of queuing behavior, I'd suggest that either you need to implement your own mechanism to accomplish the queueing (probably the easier fix), or that the threading architecture of your application could be designed in a different manner that avoids this problem (probably the more difficult fix). Brent -- Brent Casavant Dance like everybody should be watching. www.angeltread.org KD5EMB, EN34lv