From owner-freebsd-smp Tue Dec 5 13: 8: 6 2000 From owner-freebsd-smp@FreeBSD.ORG Tue Dec 5 13:08:03 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 5EEE237B400 for ; Tue, 5 Dec 2000 13:08:03 -0800 (PST) Received: (qmail 38096 invoked by uid 1142); 5 Dec 2000 21:08:02 -0000 Date: 5 Dec 2000 13:08:02 -0800 Date: Tue, 5 Dec 2000 13:07:55 -0800 From: Jason Evans To: Julian Elischer Cc: smp@freebsd.org Subject: Re: Mutex types. Message-ID: <20001205130755.C2312@canonware.com> References: <3A2D3786.5E8CC39F@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A2D3786.5E8CC39F@elischer.org>; from julian@elischer.org on Tue, Dec 05, 2000 at 10:44:22AM -0800 Sender: jasone@magnesium.net Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 05, 2000 at 10:44:22AM -0800, Julian Elischer wrote: > 1/ These aren't really very light weight. > There are cases when what is wanted is a spin-mudex that takes a couple of > instructions at most and is held for maybe 4 instructions. The mutexes > implemented in kern/kern_mutex.c > are very heavyweight, and not very suitable for fine-grain work. If you look closely at the code that actually gets executed in the common case, the mutex code is pretty streamlined. In the common case, the code in kern/kern_mutex.c never even gets called; the real action is in sys/mutex.h. Getting rid of recursion (actually making recursion available via a separate synchronization primitive) would slightly improve performance, but it isn't huge difference. > 2/ There is no such thing as a reader/writer (SIX?) mutex in the set. > Are there any plans for such? Of course one could be implemted usinghte existing > mutexes, but as they are so bloated anyhow, an attempt to do so would produce > something in the 'godzilla' range. Building SIX locks on top of mutexes would IMO be the correct way to go. Really, the mutex code isn't so bad if you look closely at what it does. > 3/ The attempt to combine all types of mutexes into one has various side > effects. > One being the sentence in the man page: > ---- > It is an error > to acquire a mutex in one mode (e.g. spin) and release it in another > (e.g. default). It is also an error to get the lock in one mode and al- > low another thread to attempt to get the lock in another mode. A good > general rule is to always use a given mutex in one mode only. > ---- > If they were differnt structures, then it wouldn't be POSSIBLE to get them wrong > if typechecking > were used in the compiler. I cannot believe that the attempt to make one > 'all-singing-and-dancing' mutex doesn't make the code and data bigger. > What were the reasons for it to be done this way? We inherited this interface from the BSD/OS code. I don't think anyone completely likes the API (in particular, having to pass in MTX_DEF or MTX_SPIN with every operation), but up to now there have been higher priorities than changing the mutex API. The main reason for the original design was flexibility during conversion of the kernel. That said, I would like to see the recursive and spin mutex support split out. Even more though, I'd like to see major portions of the kernel running outside of Giant. > 4/ I notice the comment in the man page: > ----- > This could result in deadlock if a thread interrupted > the thread which held a mutex and then tried to acquire the mutex; for > this reason spin locks will disable all interrupts (on the local CPU on- > ly) by default. > ----- > How expensive is it to disable all interrupts? I dunno, but correctness takes precedence over performance in my book. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message