Return to BSD News archive
Xref: sserve comp.os.misc:3089 comp.os.lynx:532 comp.os.386bsd.questions:10817 comp.os.lynx:533 comp.os.mach:3948 comp.os.minix:23844
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!hookup!swrinde!pipex!uknet!EU.net!sun4nl!news.nic.surfnet.nl!tuegate.tue.nl!blade.stack.urc.tue.nl!onno
From: onno@stack.urc.tue.nl (Onno Hovers)
Newsgroups: comp.os.misc,comp.os.lynx,comp.os.386bsd.questions,comp.os.lynx,comp.os.mach,comp.os.minix
Subject: Re: Need good OS for intel X86 platform. LINUX!!!
Followup-To: comp.os.misc,comp.os.lynx,comp.os.386bsd.questions,comp.os.lynx,comp.os.mach,comp.os.minix
Date: 2 Jun 1994 08:43:04 GMT
Organization: MCGV Stack, Eindhoven University of Technology, the Netherlands.
Lines: 46
Message-ID: <2sk62o$5dk@tuegate.tue.nl>
References: <1994May27.141723.13104@eplrx7.es.duPont.com> <n9044144.770068471@honeydew> <JRICHARD.94May27170016@charon.uml.edu> <2s7euj$ahp@solaris.cc.vt.edu> <2sc2g7$k3c@astfgl.edb.tih.no>
NNTP-Posting-Host: blade.stack.urc.tue.nl
X-Newsreader: TIN [version 1.2 PL2]
Ragnvald T. Blindheim (root@jedi.edb.tih.no) wrote:
> balister@maddog.async.vt.edu wrote:
> : I think preempitive multitasking means a high priority task can
> : interupt a lower priority task even if it's in the kernel. If someone has
> Processes preemted when in kernel mode? I don't think so.....
> I'm *no* Linux-guru (not even a Linux-user :-),
> but I don't think Linux can force preemption on processes while they
> are in kernel mode.
No, processes cannot be preempted when they are busy in the kernel. The
reasons for this are:
-If processes could be preempted in kernel-mode then the routines in the
kernel must be fully reentrant. This is very difficult to achieve. A second
possibility is using different threads within the kernel that use some kind
of message-passing.
But there are more reasons while Linux isn't real-time:
-The response-time to interrupts is not guaranteed. The routines in the
kernel use locking by masking the interrupts very often, and even when an
interrupt is served other interrupts are very often masked.
-A process within Linux cannot do its own scheduling, or guarantee
processor-time. System V Release 4 has something called a real-time queue
for this.
-There are no routines within the kernel that do their work within a
guaranteed time.
-Interrupt service routines cannot use all of the system calls. The reason
for this is
1) The kernel cannot be preempted.
2) An interrupt server routine cannot sleep
3) An interrupt server routine cannot copy something in a users' address
space.
I don't know if user-processes can service interrupts, but it seems very
unlikely to me.
Regards,
--
------------------------------------------------------------------------------
/-------/ / | Onno Hovers [IRCNICK=arrow]
/ /-------/ | 2nd Year student Physics
/ /-------/ | email: onno@stack.urc.tue.nl
/-------/ / | tel. : 013-676622
Ask for OHware (TM) | addr.: Wandelboslaan 105, 5042 PC Tilburg, Nederland
------------------------------------------------------------------------------
All animals are equal, but some animals are more equal than others--G.Orwell