Date: Mon, 11 Sep 2000 20:51:45 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> 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 Message-ID: <20000912035145.44B1868@pinyon.org> In-Reply-To: Message from Joerg Micheel <joerg@cs.waikato.ac.nz> of "Tue, 12 Sep 2000 14:52:55 %2B1200." <20000912145255.A41113@cs.waikato.ac.nz>
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. 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: <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 % 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?20000912035145.44B1868>