Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Nov 2001 16:24:32 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Terry Lambert <tlambert2@mindspring.com>, Matthew Dillon <dillon@apollo.backplane.com>
Subject:   Re: cur{thread/proc}, or not.
Message-ID:  <XFMail.011112162432.jhb@FreeBSD.org>
In-Reply-To: <Pine.BSF.4.21.0111121608240.94926-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <jhb@FreeBSD.org> -- 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011112162432.jhb>