Date: Sun, 24 Sep 2000 15:42:16 +0930 From: Greg Lehey <grog@wantadilla.lemis.com> To: Chuck Paterson <cp@bsdi.com> Cc: Archie Cobbs <archie@whistle.com>, Brian Somers <brian@awfulhak.org>, Joerg Micheel <joerg@cs.waikato.ac.nz>, Matthew Jacob <mjacob@feral.com>, Frank Mayhar <frank@exit.com>, John Baldwin <jhb@pike.osd.bsdi.com>, Mark Murray <markm@freebsd.org>, FreeBSD-arch@freebsd.org Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro) Message-ID: <20000924154216.D512@wantadilla.lemis.com> In-Reply-To: <200009240302.VAA20719@berserker.bsdi.com>; from cp@bsdi.com on Sat, Sep 23, 2000 at 09:02:49PM -0600 References: <200009231942.MAA06755@bubba.whistle.com> <200009240302.VAA20719@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 23 September 2000 at 21:02:49 -0600, Chuck Paterson wrote:
>
>> Once you have the spin lock primitive, you can easily build
>> semaphores, sleep queues, etc. A semaphore is just a counter plus
>> a sleep queue -- all protected by the spin lock.
>>
>> A MUTEX is just a sepaphore whose initial count is 1.
>>
>> ??
>
> In general this might be true, but in specific it isn't.
As you know, I used to say exactly the same thing as Archie, but I've
realized that this implied count of 1 causes a couple of important
differences. I'm still working on a clearer definition, but what I've
seen so far is:
1. Because "mutexes" (I really hate this term; I wish I could find a
better one) only have an implied count of one, they can also have
the concept of an owner, which we use.
2. Because the mutex has an owner, only the owner can release it.
3. The mutex can also be "recursive" (it's really iterative, I
suppose): the owner can take it several times. The only reason
for this appears to be sloppy coding, but in the short term I
think we're agreed that we can't dispose of that.
One thing that I don't think is important is the duration of
ownership. We currently use mutexes for short periods of time, which
is why we have the spin version.
At Tandem, we only used semaphores, but they always had a count of 1,
so they were effectively very close to our mutexes. They didn't allow
recursion, which is the Right Thing in a system designed from the
ground up, but they also didn't have owners. One of the most frequent
complicated problems we had were system hangs (deadlocks), and we
frequently couldn't figure out who had done what and why. Having
owners is a great debug aid.
> The sleep version of mutexs have no spin lock. Spin locks are more
> expensive than the mutices currently in FreeBSD and BSD/OS. In
> order to acquire a spin locks interrupts must be blocked, which
> isn't the case for mutices which are not contested.
If we can expect that the mutex will, on average, be freed in less
time than it would take to schedule a new process, spin locks can be a
better alternative. Otherwise we wouldn't need them at all.
Anyway, this doesn't directly relate to semaphores. We have the basic
issue of atomicity, which in general can be handled without spin
locks, and that would apply to semaphores just as much as to mutexes.
Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
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?20000924154216.D512>