From owner-freebsd-arch Mon Sep 11 20:51:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from phnxpop3.phnx.uswest.net (phnxpop3.phnx.uswest.net [206.80.192.3]) by hub.freebsd.org (Postfix) with SMTP id 2752337B422 for ; Mon, 11 Sep 2000 20:51:52 -0700 (PDT) Received: (qmail 97669 invoked by alias); 12 Sep 2000 03:51:48 -0000 Delivered-To: fixup-FreeBSD-arch@FreeBSD.ORG@fixme Received: (qmail 97507 invoked by uid 0); 12 Sep 2000 03:51:45 -0000 Received: from 63-224-154-90.customers.uswest.net (HELO pinyon.org) (63.224.154.90) by phnxpop3.phnx.uswest.net with SMTP; 12 Sep 2000 03:51:45 -0000 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by pinyon.org (Postfix) with ESMTP id 44B1868 for ; Mon, 11 Sep 2000 20:51:45 -0700 (MST) X-Mailer: exmh version 2.1.1 10/15/1999 To: FreeBSD-arch@FreeBSD.ORG 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 In-Reply-To: Message from Joerg Micheel of "Tue, 12 Sep 2000 14:52:55 +1200." <20000912145255.A41113@cs.waikato.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Sep 2000 20:51:45 -0700 From: "Russell L. Carter" Message-Id: <20000912035145.44B1868@pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %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. CVs are the natural pattern for an environment with worker thread(s) and delegator(s). You can't avoid a mutex hierarchy if you want to provide at least multithreaded R access to necessary data structures. I spend probably 50% of my time working out architectures that allow R and W access to complex data structures accessed by a slew of atomic ops. It's hard, but fun. So it's cool to see it here. An OS is a lot harder... Russell % % Joerg %-- %Joerg B. Micheel Email: %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 % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message