Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!otc!metro!bunyip!uqvax!csvax!eezprandolin
From: eezprandolin@qut.edu.au
Newsgroups: comp.sys.atari.st
Subject: Re: GEM multi-tasking interface (please!!)
Message-ID: <5064@qut.edu.au>
Date: 9 Sep 89 21:59:47 GMT
References: <8909040249.AA18031@ucbvax.Berkeley.EDU> <7845@cbmvax.UUCP>
Organization: Queensland University of Technology
Lines: 69

In article <7845@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> in article <8909040249.AA18031@ucbvax.Berkeley.EDU>, MEGGIN@vm.epas.utoronto.CA (David Megginson) says:
> 
>>    The accessory can either switch between applications using a
>> timed interrupt, or switch every time there is an OS call.  
> 
> This is much more difficult than it might seem.  I don't know much about
> GEMDOS, but I suspect that none of the function calls are re-entrant.  That
> means that interrupt driven (transparent, etc) multitasking is out.  The
> second problem is how to manage the global data areas that a program uses,
> but if you're willing to create a new kind of program that's designed for
> multitasking, this gets much easier.  The example of Apple's Multifinder 
> shows one case where an operating system not designed for multitasking can
> support a limited form of multitasking.  Multifinder swaps tasks when a 
> particular function call is made -- it's not likely safe to swap tasks on
> any function call in such a system.
> 
> Once you get tasks running together, the next thing that's necessary is control
> of task access to shared resources.  For example, it should be OK for any 
> number of tasks to read a single file, but only one should write it.
> 
>> BITNET:		David Megginson <meggin@vm.epas.utoronto.ca>
> -- 
> Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
>    {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
>                     Too much of everything is just enough

Not Really, most people assume that re-entrancy is the only way of ensuring
multitasking works, however there are other ways.

1. Trap AES calls and initiate all event waits from the M/T kernel
   distributing those events to all apps waiting.

2. Do not task switch while in Gemdos. This is easy in ROM systems the return
   address from the timer interrupt is FXXXXX !
   ( this guarantees mutex on Gemdos )

3. Add new messages for multitasking gem programs for disk I/O etc


Given the kernel dispatches periodic event calls ( with timer ) the kernel 
can control all applications access to Gemdos.

File locking can be implemented at a primative level by using the R/O flag.


Using this method TOS will THINK that only the Kernel is running on the system
each of the gem applications running will only be known to the kernel.

Ie no two programs will use TOS at the same time (kernel controlled) 
applications calling the kernel/GEM (or is it TOS ?) can be identified by
code segments or app id (as required)

Many of us lose sight of the fact that GEM is a co-operative multitasking OS
DA's are actually run round robin style and you can actually do things
in your event loop ( if you call event timer (and event timer didn't have
 bugs :-) )) Therfore gem programs must be written to be co-operative 
MULTITASKING programs. This will ease integration considerably.

If there is enough interest in the project I would suggest a council of
sorts ,there are a lot of issues here, 
( How to M/T Disk I/O , the dialog redraw/screen hogging problem and 
numerous others),

Implementation of the Kernel is the EASY bit .


BOB