From owner-freebsd-arch Sat Sep 23 23:13:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 44CB737B43C; Sat, 23 Sep 2000 23:13:37 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8O6CGe35439; Sun, 24 Sep 2000 15:42:16 +0930 (CST) (envelope-from grog) Date: Sun, 24 Sep 2000 15:42:16 +0930 From: Greg Lehey To: Chuck Paterson Cc: Archie Cobbs , Brian Somers , Joerg Micheel , Matthew Jacob , Frank Mayhar , John Baldwin , Mark Murray , 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> References: <200009231942.MAA06755@bubba.whistle.com> <200009240302.VAA20719@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009240302.VAA20719@berserker.bsdi.com>; from cp@bsdi.com on Sat, Sep 23, 2000 at 09:02:49PM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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