Re: Role of process priority in locking mechanism
From: Casper H.S. Dik (Casper.Dik_at_Sun.COM)
Date: 12/23/04
- Next message: Casper H.S. ***: "Re: File * to fd"
- Previous message: Walter Roberson: "Re: TCP MSS issue"
- In reply to: Kamal R. Prasad: "Role of process priority in locking mechanism"
- Next in thread: Nick Landsberg: "Re: Role of process priority in locking mechanism"
- Reply: Nick Landsberg: "Re: Role of process priority in locking mechanism"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 23 Dec 2004 18:34:41 GMT
kamalp@acm.org (Kamal R. Prasad) writes:
>splxxx() are a set of routines -which provide a priority level(xxx),
>which preempts other lower priority interrupts from preempting the
>code. They are used throughout the UNIX kernel, but they do not
>necessarily have anything to do with the hw. You could use splxxx()
>within an implementation of a syscall() , a device's read(), mmap(),
>ioctl() etc.. Its just to ensure atomicity of execution of a certain
>fragment of a code block.
Except that it doesn't in a Solaris kernel (there is more than one CPU)
and you also block progress of all unrelated threads; in that it
is a very primitive, coarse grained, lock.
(splnet(), e.g., locks at the network interrupts so you can safely
do administrative in the network stack)
>a primitive lock would be something like a spinlock().
Why is that primitive? Spinlocks are used a lot in MP systems
for short term waits (the Solaris kernel spins when it tries to
grab a lock held by a thread currently running on a CPU); it assumes
the lock will be short term. (It is an adaptive lock)
>Well -whether the kernel is multi-threaded or not does not ahve much
>to do with the nature of locks. Perhaps you mean, MP has a lot to with
>the implementation of locks.
>then how will you implement splnet()? Its not related to any driver.
You don't; the Solaris kernel does not have any interrupt level
manipulation routines available for use by driver writers.
>netbsd, freebsd etc.. are all examples of multi-threaded kernels that
>dont work that way You are describing an implementation.
Yes, I did not claim otherwise; threaded implementations which still
require spl*() calls are not MT-hot as those which do not.
Casper
-- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
- Next message: Casper H.S. ***: "Re: File * to fd"
- Previous message: Walter Roberson: "Re: TCP MSS issue"
- In reply to: Kamal R. Prasad: "Role of process priority in locking mechanism"
- Next in thread: Nick Landsberg: "Re: Role of process priority in locking mechanism"
- Reply: Nick Landsberg: "Re: Role of process priority in locking mechanism"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]