Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!unido!rmi!kkaempf
From: kkaempf@rmi.UUCP (Klaus Kaempf)
Newsgroups: comp.sys.amiga
Subject: Re: SetFunction()? HELP!
Keywords: .tech
Message-ID: <880@rmi.UUCP>
Date: 13 Feb 88 14:40:59 GMT
Reply-To: kkaempf@rmi.de (Klaus Kaempf)
Organization: RMI Net, Aachen, W.Germany
Lines: 49
Posted: Sat Feb 13 15:40:59 1988

Maybe we should reserve task priority -128 to solve this
problem: If a task of prio -128 gains control, the system is
probably not very busy, i. e. all other tasks must be
waiting.

So we should include something like

    pri = SetTaskPri(FindTask(NULL), -128);

after "Forbid()", and, of course, add

    (void)SetTaskPri(FindTask(NULL), pri);

before "Permit()" in UndoSetFunction().

What should we do, if a task is waiting inside our
library-patch-code? Surround all Wait()'s (or WaitBlit(),
DoIO(), whatever) by some kind of "LockFunction()" and
"UnlockFunction()".

The "ObtainSemaphore()" would only wake up, if no task is
waiting inside our patch code. Maybe it's still inside our
code, but we won't wake up until everything is quiet (prio =
-128, remember).

Now, there's another catch: What if we finally obtained the
semaphore and gained control of the system, because someone
else is waiting for this semaphore to be released? Darn,
again someone waiting inside our code. I'd suggest ...

    Forbid();

    for(;;)
     {
     ObtainSemaphore(&fn->Semaphore);
     if(fn->Semaphore.ss_QueueCount == -1)
      break;
     ReleaseSemaphore(&fn->Semaphore);
     }

    /* ... */

Oh yeah: "LockFunction()" and "UnlockFunction()" can be
derived from "LockPred()" and "UnlockPred() and the latter
should then call the former.

!ralph

Ralph Babel, Falkenweg 3, D-6204 Taunusstein, FRGermany