Date: Tue, 12 Sep 2000 14:52:55 +1200 From: Joerg Micheel <joerg@cs.waikato.ac.nz> To: Greg Lehey <grog@lemis.com> Cc: 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, joerg@cs.waikato.ac.nz Subject: Re: 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: <20000912145255.A41113@cs.waikato.ac.nz> In-Reply-To: <20000912121105.J88615@wantadilla.lemis.com>; from grog@lemis.com on Tue, Sep 12, 2000 at 12:11:05PM %2B0930 References: <200009120101.e8C11nN56928@realtime.exit.com> <Pine.LNX.4.21.0009111801490.25916-100000@zeppo.feral.com> <20000912121105.J88615@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. Joerg -- Joerg B. Micheel Email: <joerg@cs.waikato.ac.nz> Waikato Applied Network Dynamics Phone: +64 7 8384794 The University of Waikato, CompScience Fax: +64 7 8585095 Private Bag 3105 Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's 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?20000912145255.A41113>