Date: Tue, 05 Dec 2000 10:44:22 -0800 From: Julian Elischer <julian@elischer.org> To: smp@freebsd.org Subject: Mutex types. Message-ID: <3A2D3786.5E8CC39F@elischer.org>
next in thread | raw e-mail | index | archive | help
In my quest to try get netgraph SMP compatible, I've been diving into the
mutex code. Several things are noticiable.
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. is there any
plan to introduce lighter contructs? From my perspective I KNOW I won't want to
recurse so I don't want all that recursion gumpf.
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.
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?
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?
Summary.
I have a preference to having different types of mutexes with seperate
specialised functions for them. And a (SIX?) mutex would definitly be one of
them, as would a NON RECURSIVE spinlock. (that spins for about
100 machine cycles before panicing when in debug mode). Overloading
them as we are now is I think a suboptimal move..
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
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?3A2D3786.5E8CC39F>