Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Wanted: spl()ing checkers
Message-ID: <1782@umcp-cs.UUCP>
Date: Tue, 8-Oct-85 05:19:15 EDT
Article-I.D.: umcp-cs.1782
Posted: Tue Oct  8 05:19:15 1985
Date-Received: Fri, 11-Oct-85 06:36:06 EDT
References: <5237@elsie.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 21
Keywords: 4.2bsd VAX splx

In this particular case it is safe:  the spl6() in bflush() is to
protect bp->b_flags, since spl6() blocks disk operations (the things
that invoke biodone()), and the flags are actually all stashed away
by the time hpstrategy() is called.  The spl5() in hpstrategy() is
presumably to protect bp->b_cylin for disksort(); I am not convinced
that this is (a) required or (b) effective, but as you said it
obviously is not breaking anything.

`s = spl<k>();' should probably be rewritten as `s = raiseplto<k>();';
it is a rather rare event when the previous priority level is known
and/or the new level should be set regardless of the previous level.

Of course, the real problem is that raising an interrupt priority
level is not, after all, such a marvellous way of guaranteeing
exclusion.  It is simple, and that is an advantage, but (e.g.) it
makes for long interrupt latency in some cases, and does not work
well with multiple CPUs.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu