Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: Real time Unix
Message-ID: <8139@mimsy.UUCP>
Date: Tue, 25-Aug-87 02:57:30 EDT
Article-I.D.: mimsy.8139
Posted: Tue Aug 25 02:57:30 1987
Date-Received: Wed, 26-Aug-87 02:49:56 EDT
References: <1065@vu-vlsi.UUCP> <253@etn-rad.UUCP> <2862@psuvax1.psu.edu> <2340@vdsvax.steinmetz.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 27

In article <2340@vdsvax.steinmetz.UUCP> barnett@vdsvax.steinmetz.UUCP
(Bruce G Barnett) writes:
>I have always heard that Unix isn't real time because:
>
>	If a real-time event causes a change in priorities and
>	scheduling while a system call was executing, the system call
>	won't be interrupted.

This is true for at least the 4BSD kernels:  Scheduling is preemptive,
but there is no kernel preemption.

One easy way to reduce interrupt-to-user-run latency is to sprinkle
various invocations of

	if (runrun) {			/* want to run another process */
		(void) splclock();
		setrq(u.u_procp);
		u.u_ru.ru_nivcsw++;
		kern_preempt++;		/* statistics */
		swtch();
	}

calls in `safe' places in the kernel, e.g., while no inodes are held.
HP has done something like this.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris