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