Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.unix-wizards
Subject: Re: Question on how to implement exclusive scheduling
Message-ID: <154@desint.UUCP>
Date: Sat, 13-Oct-84 16:26:58 EDT
Article-I.D.: desint.154
Posted: Sat Oct 13 16:26:58 1984
Date-Received: Sun, 14-Oct-84 08:30:48 EDT
References: <620@trwspp.UUCP>
Organization: his home computer, Thousand Oaks, CA
Lines: 44

I think that a system call to prevent process switching is probably not the
right way to go.  You will run into a number of problems, the biggest of
which is that you are violating a fundamental assumption of the design of the
operating system (i.e., that it can switch processes when it wants to).  It
is impossible (at least for me) to predict where Unix would object, but I
sure wouldn't be surprised if your first attempt failed miserably and
mysteriously.

What is wrong with the famous "locking" (or "lockf") system call, which
locks access to a particular area of disk?  I even think it's on 4.2bsd.  If
not, here's an outline of an implementation:

	struct locktab {you-figure-this-part-out} locktab[NLOCK];

	locking () {
		
		while (1) {
			
			if (locked)
				sleep (&locktab_entry);
			else
				break;
		}
		
	}

	unlock () {
		
		wakeup (&locktab_entry);
	}

Since this is implemented in the kernel, it is clean and simple.  It also has
the advantage that it does not lock out the whole world when there are
probably only a few processes that are likely to be a problem (do you really
want to shut off uucp and the print spooler while you access those bytes?).
And a runaway process won't grab the CPU so it can't be killed.

Fleshing this code out is simple if you are a kernel guru.  If you are not,
you really don't have any business mucking with swtch() anyway.
-- 
	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff