Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Does the AmigaOS pre-emptively multitask?
From: lkoop@TIGGER.STCLOUD.MSUS.EDU (LaMonte Koop)
Date: 31 Aug 92 23:07:53 -0600
Reply-To: lkoop@TIGGER.STCLOUD.MSUS.EDU
Organization: St. Cloud State University, St. Cloud, MN

In article <1992Aug31.183436.42688@kuhub.cc.ukans.edu>, thompson@kuhub.cc.ukans.edu writes:
>In article <1992Aug30.170606.1070@msus1.msus.edu>, lkoop@TIGGER.STCLOUD.MSUS.EDU (LaMonte Koop) writes:
>>     As a matter of fact, it does interfere with real-time operations.
>> Programmers are urged to avoid calls such as Forbid() unless it is strictly
>> necessary (such cases do exist, such as when traversing system shared
>> resource lists, etc...so they aren't modified while you are grabbing the next
>> pointer in the list (and throw yourself out in the weeds :) )).
>>     AmigaOS basically has two levels of these special calls (not counting
>> priority considerations).  Forbid() halts all task switches, leaving the
>> calling program in complete control until a Permit() call is made.  HOWEVER,
>> if the program under Forbid() ends up waiting for I/O, (in such was as doing
>> a Wait() on a port or I/O device), the Forbid()'en state is "broken" until
>> the I/O or other waiting situation is satisfied, at which time the state is
>> re-entered.  This allows other tasks/processes CPU time while the Forbid()'en
>> program is waiting.  Note that breaking a Forbid() can occur during a system
>> call as well, if for some reason the system call has to do a Wait(), etc.
>>     The next, more drastic level in the context is a call to Disable().
>> Disable() basically stops all interrupt processing (Disables interrupts),
>> and in effect also stops all task switching, as this is interrupt-driven.
>> The Disable()'ed state remains in effect until a call to Enable() is given,
>> or the same circumstances as with a Forbid() being broken are encountered.
>> 
>
>Does all this mean that the AmigaOS does not have pre-emptive
>multitasking?  If a programmer can design his application to tie
>up the system, does this mean that the system is not strictly
>pre-emptive?

    No.  When under a Forbid() or Disable(), the system is basically NOT 
multitasking at all (unless the state is broken, as per mentioned earlier).
This does not imply a non pre-emptive multitasking system.  It simply
implies a method exists for holding the processor to a specific task for
special reasons.
    Look at it this way: under program switching or cooperative multitasking,
any specific process must of its own accord give up the processor for another
task.  Note that this is NOT what is occuring above.  The system will 
pre-emptively multitask UNLESS a special circumstance warrants a call to the
above..and even then as per originally stated, this will be broken should
the task in question have to wait.  Basically this is pre-emptive multitasking
in its normal form: task switching will occur normally and pre-emptively
unless rather special measures are taken.

                 ----------------------------------------
           LaMonte Koop -- SCSU Electrical/Computer Engineering
 Internet: lkoop@tigger.stcloud.msus.edu -OR- f00012@kanga.stcloud.msus.edu
              "You mean you want MORE lights on this thing???"
 ---------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.advocacy