Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.COM (Terry Ingoldsby)
Newsgroups: comp.os.os9
Subject: Re: Interrupt handling error in most OSK drivers ???
Summary: Does this apply to OS9 too?
Message-ID: <432@ctycal.UUCP>
Date: 17 Aug 89 18:58:34 GMT
References: <1772@ethz.UUCP>
Organization: The City of Calgary, Ab
Lines: 45

In article <1772@ethz.UUCP>, zeller@ethz.UUCP (Lukas Zeller) writes:
 > I am using and programming OS-9/68k for several years now.  I  have  written
 > some drivers from scratch and I have  modified  many  existing  drivers  for
...
 > The problem can occur in all I/O-drivers that initiate some  action  in  the
 > main process and then do an infinte sleep.  The  completion  of  the  action
... 
 > The standard outline for an interrupt controlled I/O driver is  as  follows,
 > according to existing source code as well as to P.Dibble's "OS-9  Insights",
 > paragraph 20.6:
 > 
 >    repeat
 >         mask interrupts
 >         if (IO request cannot be satisfied until hardware
 >             generates an interrupt) then
 >             UNMASK INTERRUPTS
 >             sleep
 >             continue
 >    until (IO request can be satisfied)
 > 
 > Now, what happens if the interrupt occurs *after* the decision that we  need
 > to wait for an interrupt, but *before* the main  process  is  asleep  ?  The
 > interrupt routine is called immediately after the "UNMASK  INTERRUPTS"  step
 > and sends a wakeup signal to the main process. But the main process  is  not
 > sleeping yet and thus  the  wakeup  signal  is  ignored  (according  to  the
 > documentation S$Wake insures only that the process is running and will *not*
 > be queued). Then the main process goes to sleep and will remain sleeping for
 > ever, because the wakeup event has occurred already before it went to sleep.

Its been a while since I did much driver level programming in OS9, but I seem
to remember wondering how you were supposed to get around this problem.  Is the
fix you propose
 > 
 > MUST NOT BE ENABLED BEFORE THE MAIN PROCESS IS ASLEEP. The only way to match
 > this condition is to call F$Sleep WHILE THE INTERRUPTS ARE  STILL  DISABLED,
 > and relying on the F$Sleep itself enabling the interrupts when it is safe. I

also legal in OS9?  If so, could MicroWare please tell us what other system
calls clear the interrupts?  (both in OSK and OS9).


-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb