Date: Thu, 1 Jul 1999 11:10:19 -0500 From: "Mike Avery" <mavery@mail.otherwhen.com> To: freebsd-newbies@FreeBSD.ORG Subject: Re: reentrant kernel Message-ID: <199907011611.LAA02469@hostigos.otherwhen.com> In-Reply-To: <199907010116.VAA94928@freedom.cybertouch.org> References: <377A1428.4145F218@charm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 Jun 99, at 21:17, Lanny Baron wrote:
> Just a quick question. What is a reentrant kernel?
Not sure that's a quick question....
<Warning - gross simplifications and dated generalizations ahead>
Re-entrancy refers to the ability of code to be invoked as often as
needed by any caller.
When you have a single-tasking, single-user OS (like DOS, for
instance), re-entrancy isn't an issue. You have one task running, and
re-entry of a module won't happen (with the possible exception of
recursion...)
When you have a multi-tasking and/or multi-user OS (like Unix, Linux,
FreeBSD, UniFLEX, OS/9, VMS, Multics, WinNT, and just about any
mini or main-frame OS), you have the possibility that several tasks,
or users, could access the same code at the same time. Maybe the
"open file" module.
So... you have to do something to prevent my attempt to open a file
from interfering with your attempt to open a file. You can put code
in the scheduler, and perhaps in the modules, to insure that only one
task will attempt to open files at any given time. This is often called
blocking. Perhaps you could have a queue in front of the file open
routine, so a task requests a file open by queueing the request, and
then waiting for results or a time-out. This works, and works well.
But, it still delays things. Why should you have to wait for me to
finish opening a file when your file isn't even on the same drive?
Handling that sort of scenario adds to the code. And, in any case,
you have a situation where everyone who has to perform a function,
like opening a file, has to wait until other requests have been
serviced. Not because of hardware limitations, but because of
software limitations.
The keys here are usually how temporary variables and work spaces
are handled. You can't use the same memory location to handle
more than one set of data at the same time.
The answer then is to dynamically allocate the needed work space,
to insure that each task that wants to open a file can not interfere
with any other task that's doing the same thing. Back in my assembly
language programming days on a Singer System 10, we'd use space in
the task's dedicated memory partition (the hardware partitioned the
memory, each user got up to 10k {that's right, k} of core {real core...
magnetic doughnuts in a wire matrix}). On the Motorola 6809, we'd
handle the situation by letting each task have it's own stack, and
refering to the task's stack for storage. Either way, we had
storage that other tasks couldn't wipe out. (Well... the well behaved
tasks didn't wipe each other out. At that time memory protection
was software based and poorly written code could crash the
system... since then hardware protection has become available... it's
faster and more stable, and requires less software to support it.)
When the kernel is re-entrant, that means that all system tasks
should be re-entrant, so there should be no blocking for purely
software reasons. There will probably still be some situations where
there will be blocking, however. In the file open example, for
instance. The open request would check the cache, and if the file is
cached, the open may not even hit the disk. However, if the file is
not cached, the request will hit the disk... and a disk is physically
constrained to only be able to do one thing at a time. So, a blocking
mechanism must exist at this point. However, in a well designed OS,
running on a well-tuned server, the impact of the actual disk
hardware should be (relatively) minimal.
Hope that helps,
Mike
======================================================================
Mike Avery MAvery@mail.otherwhen.com
(409)-842-2942 (work)
ICQ: 16241692
* Spam is for lusers who can't get business any other way *
A Randomly Selected Thought For The Day:
DEC has it now! Unfortunately, it's on back order.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-newbies" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907011611.LAA02469>