From owner-freebsd-stable@FreeBSD.ORG  Thu May 15 12:57:21 2008
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from alona.my.domain (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP id DCBE7106566C;
	Thu, 15 May 2008 12:57:17 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
Message-ID: <482C3333.1070205@freebsd.org>
Date: Thu, 15 May 2008 20:57:23 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Thunderbird 2.0.0.9 (X11/20080323)
MIME-Version: 1.0
To: Andriy Gapon <avg@icyb.net.ua>
References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org>
	<482BF5EA.5010806@icyb.net.ua> <482BFCE3.7080704@freebsd.org>
	<482C0206.1050206@icyb.net.ua>
In-Reply-To: <482C0206.1050206@icyb.net.ua>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-stable@freebsd.org, Brent Casavant <b.j.casavant@ieee.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
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 May 2008 12:57:21 -0000

Andriy Gapon wrote:
>
> Maybe. But that's not what I see with my small example program. One 
> thread releases and re-acquires a mutex 10 times in a row while the 
> other doesn't get it a single time.
> I think that there is a very slim chance of a blocked thread 
> preempting a running thread in this circumstances. Especially if 
> execution time between unlock and re-lock is very small.
It does not depends on how many times your thread acquires or 
re-acquires mutex,  or
how small the region the mutex is protecting. as long as current thread 
runs too long,
other threads will have higher priorities and the ownership definitely 
will be transfered,
though there will be some extra context switchings.

> I'd rather prefer to have an option to have FIFO fairness in mutex 
> lock rather than always avoiding context switch at all costs and 
> depending on scheduler to eventually do priority magic.
>
It is better to implement this behavior in your application code,  if it
is implemented in thread library, you still can not control how many
times acquiring and re-acquiring  can be allowed  for a thread without
context switching, a simple FIFO as you said here will cause dreadful
performance problem.