Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: net.lang.c++ Subject: Re: Re-entrancy Re-visited Message-ID: <1637@brl-smoke.ARPA> Date: Sat, 8-Mar-86 17:48:35 EST Article-I.D.: brl-smok.1637 Posted: Sat Mar 8 17:48:35 1986 Date-Received: Tue, 11-Mar-86 01:08:39 EST References: <34200005@orstcs.UUCP> <6812@boring.UUCP> Reply-To: gwyn@brl.ARPA Organization: Ballistic Research Lab (BRL) Lines: 35 In article <6812@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: >*any* intelligent I/O subsystem will have to keep some sort >of internal data structures, and an interrupt routine will >immedeately blow the program away as soon as it tries to do >I/O. Or, even worse, it will blow the program away two years >later, when you've long gone somewhere else. Well, if one can implement an atomic semaphore (I know how to do this for a PDP-11 or a VAX), one can implement "conditional critical regions" to protect data structures from being clobbered by asynchronous interrupts. The 3B20A UNIX kernel uses semaphores for this purpose (it's the only symmetric multiprocessor implementation of UNIX that I am aware of). SVR2 STDIO makes a valiant attempt to permit use of STDIO routines from interrupt handlers. However, ... >The only safe things to do in an interrupt routine are >- setting the InterruptHasOccurred flag, >- longjmp >- exit. ... I agree with these sentiments, mostly. I wouldn't even say that longjmp is safe, since while the (non-interrupt) manipulation of data structures is occurring, they will be in an inconsistent state that could cause trouble later if the manipulations are not allowed to complete. To implement operating systems, however, the problem of asynchronous interrupts must be solved. Methods for parallel processing have been published in the past decade or so that are relevant to this issue. Ultimately one needs an atomic synchronizer and a queue to put blocked tasks on when they attempt to enter a locked region. (A blocked task is allowed to proceed when the locker leaves the shared region.) This seems like far too much complexity for normal user-mode applications, though, unless implemented as a package or class (probably with a small assembly-language locking module).