From owner-freebsd-arch Mon Nov 12 16:24:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 27D6F37B41B for ; Mon, 12 Nov 2001 16:24:38 -0800 (PST) Received: (qmail 70062 invoked from network); 13 Nov 2001 00:24:37 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Nov 2001 00:24:37 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 12 Nov 2001 16:24:32 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: Re: cur{thread/proc}, or not. Cc: freebsd-arch@FreeBSD.org, Robert Watson , Terry Lambert , Matthew Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13-Nov-01 Julian Elischer wrote: > > > On Mon, 12 Nov 2001, Matthew Dillon wrote: > >> You want to be very careful not to bloat the concept. We >> already have severe bloatage in the mutex code and that has >> led to a lot of unnecessary complexity. A huge amount, >> in fact. We have so many types of mutexes it makes my >> head spin and I'm not very happy about it. Forget about >> 'shared' verses 'exclusive'. A reference count is a >> reference count, that's all. If you keep the concept >> simple you can implement more functionality horizontally >> rather then implementing more complexity vertically. >> >> For example, consider this API for pool mutexes. > > [...] > > weren't you just complaining that there were too many kinds of mutex? > I'm not sure how this fits under "reference counting API" > > ANyhow can you explain the idea of a pool mutex more clearly? Heh, think of it as a pool of mutexes, not a different type of mutex. Instead of having 1 mutex for each object, you use a hash table of mutexes for a set of objects. Thus, if you have 50 objects vs. 500 objects, if you embed 1 mutex for each object, you bloat each object and have 500 locks instead of 50 locks. Using pool mutexes, you only have N number of mutexes regardless of the number of mutexes. Note that if pool mutexes are non-recursive, they can't be safely used when you might have more than one object of a given set locked at a time. For example, process locks are the only object we do this with currently. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message