From owner-freebsd-newbies Fri Jul 2 5:37: 6 1999 Delivered-To: freebsd-newbies@freebsd.org Received: from nile.intac.com (nile.intac.com [198.6.114.2]) by hub.freebsd.org (Postfix) with ESMTP id E275814E9A for ; Fri, 2 Jul 1999 05:37:02 -0700 (PDT) (envelope-from gkaplan@castle.net) Received: from castle.net (parsip-usr-85.intac.com [199.173.8.156]) by nile.intac.com (8.9.3/8.9.3/ktb) with ESMTP id IAA29715; Fri, 2 Jul 1999 08:36:56 -0400 (EDT) Message-ID: <377CB229.6C1ECA8D@castle.net> Date: Fri, 02 Jul 1999 08:35:53 -0400 From: gkaplan X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: mavery@mail.otherwhen.com Cc: freebsd-newbies@FreeBSD.ORG Subject: Re: reentrant kernel References: <377A1428.4145F218@charm.net> <199907011611.LAA02469@hostigos.otherwhen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-newbies@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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.... > > > > 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