From owner-freebsd-arch Mon Sep 11 20: 2: 6 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 3CCFB37B622; Mon, 11 Sep 2000 20:02:00 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8C31E505290; Tue, 12 Sep 2000 12:31:14 +0930 (CST) (envelope-from grog) Date: Tue, 12 Sep 2000 12:31:14 +0930 From: Greg Lehey To: Joerg Micheel Cc: Matthew Jacob , Frank Mayhar , John Baldwin , Mark Murray , FreeBSD-arch@freebsd.org Subject: 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: <20000912123114.K88615@wantadilla.lemis.com> References: <200009120101.e8C11nN56928@realtime.exit.com> <20000912121105.J88615@wantadilla.lemis.com> <20000912145255.A41113@cs.waikato.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000912145255.A41113@cs.waikato.ac.nz>; from joerg@cs.waikato.ac.nz on Tue, Sep 12, 2000 at 02:52:55PM +1200 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 Tuesday, 12 September 2000 at 14:52:55 +1200, Joerg Micheel wrote: > On Tue, Sep 12, 2000 at 12:11:05PM +0930, Greg Lehey wrote: >> On Monday, 11 September 2000 at 18:02:26 -0700, Matt Jacob wrote: >>>> Greg Lehey wrote: >>>>> I've been wondering whether we shouldn't associate mutexes with data >>>>> structures rather than code. It's possible that it would make it >>>>> easier to avoid deadlocks. Thoughts? >>>> >>>> Speaking as a BSD/OS (and former Unixware) developer: YES! >>> >>> Hmm. I would rather have assumed that this is what mutexes are >>> about. Semaphores gate entry in code. Mutexes provide locking on >>> data. Simple enough. >> >> That's a matter of definition. The big difference I see between a >> semaphore and a blocking "mutex" is that there's no count associated >> with the blocking "mutex": it's a degenerate case of a semaphore. >> >> At Tandem, we used semaphores exclusively (well, we had a mutex >> instruction, but it was really interrupt lockout). As far as I can >> recall, the semaphore counter was always 1, so the effect was >> identical to the current blocking "mutexes". > > I liked the model Sun chose for Solaris. They have mutex', rw_locks, > condition variables. I don't like semaphores. What's the difference between a mutex and a semaphore? > Mutexes are for short locks. Condition variables are for long-term > waits, they are associated with a mutex. You can only sleep/wakeup a > CV when holding the associated with it, which prevents races. When > having to sleep on a CV the kernel would unlock the mutex and > reaquire it for the running thread before returning. Yes, that's pretty much what msleep() does. We're still discussing whether we should have real condition variables. 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