Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Multitasking on a II
Message-ID: <10761@ucrmath.ucr.edu>
Date: 22 Dec 90 21:22:58 GMT
References: <1990Dec20.184254.16292@nntp-server.caltech.edu> <10739@ucrmath.ucr.edu> <2772A18A.3472@ics.uci.edu>
Organization: University of California, Riverside
Lines: 51


>Why not?

>When the resource is initialized by the system:
>resource_init   ...             ;blah, blah, blah
>                lda #1          ;could be $ff if you prefer to
>                sta flag        ; grab resource with inc
>                ...             ;blah, blah, blah
>
>Then for each process that wants a piece of the action:
>your_code       ...             ;blah, blah, blah
>loop            dec flag        ;try to grab resource
>                beq locked      ;got it!
>                inc flag        ;undo attempt
>                jmp loop        ;block until available
>locked          ...             ;Here you get exclusive use of the resource.
>release         inc flag        ;undo resource lock
>                ...             ;blah, blah, blah

>I think this should work for about 254 processes.  With a slight
>variation on this theme, you can also implement non-blocking resource
>contention.


Sorry, this won't work for a variety of reasons.  Let me offer two (above and
beyond the 255 process "limitation"):

1) Consider the situation where P1 has a resource that P2 wants.  Presumably
   the flag contains zero because P1 owns the resource.  Now suppose that
   P2 decrements the flag and gets interrupted by P3 *before* the inc flag
   (after the beq above).  P3 will *never* be able to gain access to these
   resource until *after* P2 gets it.  Even if P1 gives it up in the meantime.
   Assuming P2 eventually runs again (which isn't a safe assumption) P3 will
   eventually get the resource, but the result it poor resource scheduling.
   If P2 doesn't run again for another hour, P3 will have to wait for (at
   least) an hour before gaining access to the resource even if P1 returned
   it a second after P2 asked for it.

2) Suppose the interrupt occurs after the dec flag but before the beq
   instruction.  The flag now contains -1.  Suppose P3 comes along and
   decrements the flag and gets suspended before the beq.  The flag now
   contains -2.  Now suppose P1 releases the resource and increments the
   flag.  The flag now contains -1.  I can imagine a scenerio where P2 and
   P3 constantly increment and decrement the flag out of phase, forming
   a deadlock even though the resource is available.

Nice try.  Handling degenerate cases like this  is *HAIRY*!  I look forward
to your next attempt!  Like I said, I'm not sure it *can't* be done using
INC and DEC.
*** Randy Hyde
.