From owner-freebsd-arch@FreeBSD.ORG  Sat Mar 29 10:12:32 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 53F501065676;
	Sat, 29 Mar 2008 10:12:32 +0000 (UTC)
	(envelope-from hselasky@c2i.net)
Received: from swip.net (mailfe09.swipnet.se [212.247.155.1])
	by mx1.freebsd.org (Postfix) with ESMTP id EB87D8FC1C;
	Sat, 29 Mar 2008 10:12:30 +0000 (UTC)
	(envelope-from hselasky@c2i.net)
X-Cloudmark-Score: 0.000000 []
Received: from [62.113.132.89] (account mc467741@c2i.net [62.113.132.89]
	verified) by mailfe09.swip.net (CommuniGate Pro SMTP 5.1.13)
	with ESMTPA id 702449625; Sat, 29 Mar 2008 10:12:18 +0100
From: Hans Petter Selasky <hselasky@c2i.net>
To: freebsd-arch@freebsd.org
Date: Sat, 29 Mar 2008 10:13:28 +0100
User-Agent: KMail/1.9.7
References: <10004.1205307334@critter.freebsd.dk>
	<20080312152744.I29518@fledge.watson.org>
	<20080328202602.N72156@desktop>
In-Reply-To: <20080328202602.N72156@desktop>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200803291013.28797.hselasky@c2i.net>
Cc: arch@freebsd.org
Subject: Re: timeout/callout small step forward
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Mar 2008 10:12:32 -0000

Hi,

How does this patch handle when multiple callouts use the same mutex ? Imagine 
that two threads are about to lock the same mutex, then the second thread 
will get nowhere while waiting for the first thread to execute the callback.

I think the solution is that callbacks are put in a tree. Giant locked 
callbacks go all into the same tree. Else the user of callouts is responsible 
for making up the tree.

struct callout {
	struct thread *exec_td;
	struct callout *parent;
};

struct callout *c;

while (c->parent != NULL) {
	c = c->parent;
}

if (c->exec_td != NULL) {
	callout should go into the same thread;
} else {
	pick the next free thread and set "c->exec_td"
}

Callouts that belong to the same tree are run from the same thread. This does 
not only apply for callouts, but also multithreaded node systems ...

Yours
  --HPS