Newsgroups: comp.os.minix
Subject: Re: Hardware Interrupt Under Minix
References: <8968sm$rs7$1@info.sta.net.cn>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <38b6ded9@news.isc.rit.edu>
Date: 25 Feb 2000 14:58:17 -0500
X-Trace: 25 Feb 2000 14:58:17 -0500, grace.isc.rit.edu
Lines: 42
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.oz.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!news.ecn.ou.edu!newsfeed.berkeley.edu!newsfeed.nyu.edu!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.oz.au comp.os.minix:34780

In article <8968sm$rs7$1@info.sta.net.cn>,
Eric Miao <EricMiao@citiz.net> wrote:
>According to the default behavior of i8259 interrupt controller,
>i8259 will set the corresponding IRQ mask in its register when
>a certain IRQ occurs. In macro _hwint, it sets the IRQ mask
>manually. Is this step here to ensure the same interrupt will
>not occur later or can be omitted?

Most likely, it is unnecessary, but I'll let someone else who knows the
x86 stuff better than I do give a final answer.

>And a silly question, can I say that the same interrupt handler
>can not be reenterable if it is to modify some shared variables.

That's an overgeneralization, although it's basically correct.  Under a
few conditions, it is possible that your handler could be reentrant and
still modify shared variables.  Precisely what conditions depend on the
processor architecture (what atomic operations exist), the compiler (of
the atomic operations, what code compiles to produce them), and perhaps
a couple of other things.  Simply setting a flag to a fixed value won't
generally cause race conditions; examining it before changing it could.

Bear in mind, too, that hardware device registers are shared variables,
as are local variables declared static inside a function.

In Minix, I don't think having re-entrant interrupt handlers would gain
anything much, since most of them just wake up the appropriate task.

(It is of utmost importance, of course, that non-maskable interrupts be
given reentrant handlers.  I had to debug a quite nasty problem once on
some older hardware which was caused by violating this principle.  This
particular system used a software dynamic ram refresh scheme, whcih was
triggered every now and again by a periodic interrupt.  The handler was
pretty simple; it temporarily disabled the cache (storing the old cache
control register contents in a fixed location), executed a bunch of NOP
instructions carefully placed to access every row in RAM, restored what
the old cache state was, and exited.  If there was a lot of bus conten-
tion (due to DMA), it could actually be re-entered, with the net effect
that the cache was disabled and the system slowed down greatly.)

-- 
Andrew Erickson
