From owner-freebsd-arch@FreeBSD.ORG Mon Mar 6 18:53:29 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABCBA16A420; Mon, 6 Mar 2006 18:53:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADDDE43D4C; Mon, 6 Mar 2006 18:53:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k26IrM68019774; Mon, 6 Mar 2006 13:53:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org, dima <_pppp@mail.ru> Date: Mon, 6 Mar 2006 13:53:10 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603061353.13756.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1315/Sun Mar 5 05:31:57 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: arch@freebsd.org, Poul-Henning Kamp , Robert Watson Subject: Re: wakeup idea... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 18:53:29 -0000 On Monday 06 March 2006 08:45, dima wrote: > >> Here is a possibly stupid idea. > >> > >> Historically sleep/wakeup have happened on a pointer which was just a magic > >> number. > >> > >> In many cases, this pointer is actually a relevant datastructure. > >> > >> Would it possibly be an optimization to make a variant of the sleep/wakeup > >> calls where the pointer points to an integer type which contains non-zero if > >> anybody is actually sleeping on that address ? > >> > >> Anybody up for a quick prototype ? > > > > In principle this is part of the point of a condition variable, which > > associates a struct with waitable conditions, and includes an int that > > contains the number of waiters: > > > > struct cv { > > const char *cv_description; > > int cv_waiters; > > }; > > > > Presumably the tricky bit is optimizing this such that you avoid undesirable > > races. (But maybe if you call cv_signal without the condition mutex held, you > > accept that race by definition?) > > I'm working on a new implementation of SX locks: http://wikitest.freebsd.org/moin.cgi/Usable_20lock_20implementation_20with_20SX_2dsemantics > Direct handoff (as described in "Solaris Internals") seems to do the trick. You just don't need any additional mutex for wakeup process since the current owner chooses who and when to wakeup. > Since CV-s and SX-es have very similar semantics I describe my ideas here. We would need 2 list-like datastructures: > 1. Current holders (for proper priority propagation) > 2. Current waiters (for direct handoff) > The first one can be implemented as an array; the reason of such a design decision is to avoid locking at SX acquire. The second list needs to be implemented as a (sorted by priority) queue (TAILQ for now) which needs a mutex for consistency. You might want to look at src/sys/kern/kern_rwlock.c in CVS HEAD. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org