From owner-freebsd-newbies Thu Jul 1 9:11: 7 1999 Delivered-To: freebsd-newbies@freebsd.org Received: from hostigos.otherwhen.com (mavery-gw.pernet.net [205.229.2.17]) by hub.freebsd.org (Postfix) with ESMTP id DBACB14E58 for ; Thu, 1 Jul 1999 09:10:54 -0700 (PDT) (envelope-from mavery@mail.otherwhen.com) Received: from mail.otherwhen.com (mail.2.229.205.in-addr.arpa [205.229.2.19] (may be forged)) by hostigos.otherwhen.com (8.8.6/8.7.3) with ESMTP id LAA02469 for ; Thu, 1 Jul 1999 11:11:17 -0500 (CDT) Message-Id: <199907011611.LAA02469@hostigos.otherwhen.com> Received: from PORKY/SpoolDir by mail.otherwhen.com (Mercury 1.45); 1 Jul 99 11:10:57 -0600 Received: from SpoolDir by PORKY (Mercury 1.45); 1 Jul 99 11:10:28 -0600 From: "Mike Avery" To: freebsd-newbies@FreeBSD.ORG Date: Thu, 1 Jul 1999 11:10:19 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: reentrant kernel Reply-To: mavery@mail.otherwhen.com In-reply-to: <199907010116.VAA94928@freedom.cybertouch.org> References: <377A1428.4145F218@charm.net> X-mailer: Pegasus Mail for Win32 (v3.12) Sender: owner-freebsd-newbies@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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