Date: Tue, 5 Dec 2000 13:07:55 -0800 From: Jason Evans <jasone@canonware.com> To: Julian Elischer <julian@elischer.org> Cc: smp@freebsd.org Subject: Re: Mutex types. Message-ID: <20001205130755.C2312@canonware.com> In-Reply-To: <3A2D3786.5E8CC39F@elischer.org>; from julian@elischer.org on Tue, Dec 05, 2000 at 10:44:22AM -0800 References: <3A2D3786.5E8CC39F@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001205130755.C2312>