NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/os2/misc/27433

Internet Message Format | 1992-08-14 | 3.8 KB

Xref: sparky comp.os.os2.misc:27433 comp.os.os2.programmer:4233
Newsgroups: comp.os.os2.misc,comp.os.os2.programmer
Path: sparky!uunet!wupost!darwin.sura.net!jvnc.net!princeton!newross!elan!mg
From: mg@elan (Michael Golan)
Subject: Re: Request for info about kernel pre-emption and priorities
Message-ID: <mg.713847158@elan>
Sender: [e-mail] (USENET News System)
Organization: Princeton University, Dept. of Computer Science
References: <[e-mail]>             <[e-mail]> <[e-mail]>
Date: 15 Aug 92 02:52:38 GMT
Lines: 61

[e-mail] (Peter Forsberg) writes:
>When a thread has entered the kernel, it is allowed to execute there
>until it either exits the kernel or waits for some event (I/O etc.).
>No other thread will be dispatched as long as the kernel thread is still
>running. The kernel thread can be interrupted by a hardware
>interrupt at any time though (unless it has disabled interrupts).
>When the thread is about to exit the kernel it calls the dispatcher,
>which decides if a context switch should occur. Of course a context
>switch always occurs when the thread in the kernel waits for an event.

>Disclaimer: This posting represents the poster's views, not those of IBM

Is this the last word on this subject? Thanks god, I was about to go
read my OS books again :-)

The above means that OS2's kernel is designed just like most (if not all)
kernels:
1) when a thread executes a system call, the system call executes in the
   kernel until it *decides* to release control (= wait for event =
   co-operative multi-tasking internally to the kernel).
2) Some system calls decide to release control just because they take long
   and see that some high-priority process is waiting. but from the technical
   point this is just like the system-call putting itself to sleep for an
   event. Hack this is probably implemented as a 'wait for event' where
   the event is 'no more high-priority tasks on the ready queue'...
   (or even more simple: release control once. it returns to you if no
   high-priority task exist. else they execute and then return to you)
3) OS2 kernel differs from Unix in that a systemcall check if a high-priority
   process is waiting before it returns. Otherwise it is pretty similar
   (in general! I know it differs a lot)
4) hardware interrupts can of course occur even in kernel mode. Their
   processing occur immediately, which can wake up some high-priority
   processes. these processes can continue execution, in turn, when the
   existing system call (as in (1) and (2)) ends or release cpu control.
   of course if this happens in user mode, the user thread IS preempted.

So:
* No magic, no 'multi threaded kernel' nor 'preemptinve kernel',
  which are weird (and I think expensive. Anyone know of a commercial
  widely used system designed that way?)
* the 4ms (6?) delay is the time for a kernel system call to end, or
  release control (worst case for worst sys call)
* unlike god-damn Unix, OS2 will preempt user processes in user mode or
  at the end of their kernel mode to run high-priority processes.
  oops i mean threads

(I didn't read anything specific about OS2 internals except this group, BTW.
the above is my guesstimate/understanding)

Now what was this nonsense about making the kernel 'completely re-entrant
and preemptive'? Did I hear that IBM is redesigning the whole thing, or
simply looking into some slow sys-calls to make them give control,
voluntarily more often/in more cases (which, as a result, requires more
semaphores to be put in to make those calls re-entrant)? Which one is it:
1) A bad rumor (not the post I followed up, BTW)
2) A total new amazing design of a truly preempting kernel
3) An improvement of some of the more sluggish syscalls to put this 4ms figure
   down to 1ms or so?

-- Michael Golan
   [e-mail]