🚀 go-pugleaf

In article <1990Oct4.195348.8975@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis)
writes:
>
> Ok, here's the overview:  I've got a group of related tasks (in multiples
> of 3--don't ask why) that are going to be waiting on about a half dozen
> signals each, and each signaling each other.  Every now and then, each of
> these tasks has to go off and think a while--several seconds worth of
> floating point calcs--and then signal a few tasks and Wait().  What tasks
> get signaled depends on which tasks have been given the mosts time slices.
> This explanation is never going to make sense without giving about 20 pages
> of background, and there are probably other ways to get the same effect, but
> what I want is a public struct that all these tasks can read, with one 
> ULONG per task which is a count of the number of time slices each task
> has been given.

I'm sorry to disappoint you, but you are asking for something that you simply
cannot get. Although the Quantum and Elapsed variables in the ExecBase
structure which should give you an idea of how many quantums have been elapsed,
(the quantum is supposedly incremented every vertical blank) these are awfully
unreliable. Strike one.

A second option would be to use the tc_Switch and tc_Launch vectors of the Task
structure.  If the TB_SWITCH flag of the tc_Flags entry is set, then the
routine pointed to by tc_Switch is called every time your task is switched out
and another one is started. If the TB_LAUNCH flag of the tc_Flags entry is set,
then the routine pointed to by tc_Launch is called every time your task is
about to be restarted again.

Unfortunately, the tc_Switch and tc_Launch functions will be running in
supervisor mode, therefore you will not be able to call the timer.device
functions to find out what the current time is. Strike two.

Therefore you have to take over the 16-bit counters of the CIA B timer
yourself, and count the time yourself, while making sure you're keep track of
when the counters wrap-around.

But even if you manage that, interrupts still occur and are processed under
your task's context. (kind of - tc_Switch and tc_Launch will not be called
during interrupt occurances) Therefore the time count that you keep will be
rather useless since you do not know how much time was spent inside your task,
and how much was spent processing interrupts, particularly when talking about
a granularity of a fraction of a second. Strike three, you're out of luck.

> The process I'm modeling is perfectly simulated by the round-robin
> run-if-ready scheduling that exec is already doing.

Kind of. The exec's scheduling algorithm can be viewed as an idealistic
round-robin algorithm, but some implementation details remind us that we
do not live in Utopia.

Valentin
-- 
The Goddess of democracy? "The tyrants    Name:    Valentin Pepelea
may destroy a statue,  but they cannot    Phone:   (215) 431-9327
kill a god."                              UseNet:  cbmvax!valentin@uunet.uu.net
             - Ancient Chinese Proverb    Claimer: I not Commodore spokesman be