Date: Fri, 02 Jul 1999 08:35:53 -0400 From: gkaplan <gkaplan@castle.net> To: mavery@mail.otherwhen.com Cc: freebsd-newbies@FreeBSD.ORG Subject: Re: reentrant kernel Message-ID: <377CB229.6C1ECA8D@castle.net> References: <377A1428.4145F218@charm.net> <199907011611.LAA02469@hostigos.otherwhen.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My opinion: The comments by Mike Avery seem to the point and well written.
Reentrant code is a necessary condition for smp, it is not sufficient. A
second necessary condition is that there must be the ability for one cpu to
"lock out" any other cpu in a computer system from crucial data elements -
such as a queue header pointer to a work schedule. "Lock out" would most
conveniently be done in hardware, for example a cpu instruction that would
test and modify a memory location is a single memory cycle.
Mike Avery wrote:
> 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
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?377CB229.6C1ECA8D>