Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!wuarchive!zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!mephisto!mcnc!ecsgate!ecsvax!utoddl
From: utoddl@uncecs.edu (Todd M. Lewis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Task Switching Problem
Message-ID: <1990Sep27.141415.29158@uncecs.edu>
Date: 27 Sep 90 14:14:15 GMT
References: <1990Sep21.180100.28580@uncecs.edu> <14593@cbmvax.commodore.com>
Organization: UNC Educational Computing Service
Lines: 27

In article <14593@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes:
>In article <1990Sep21.180100.28580@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes:
>>
>>  * how does one get the currently running task to relinquish
>>    the CPU for the rest of the current time slice?  I want to
>
>There used to be function call available that allowed a task to relinquish
>the CPU to some other ready task, but that function has been made private.
 [ . . . ]
>The proper way for tasks to synchronize is through signalling and waiting.
>The availability of a Relinquish() call would incite novice programmers to
   [... do evil things . . . ]
>This kind of programming practice must be avoided. The proper thing to do is
>to make the Relinquish() call unavailable.

Ok, I can buy that.  I'll try this instead--I'll make two tasks which
signal each other and wait on each other's signals.  One of these will do
the monitoring I want to have, while the other will be there simply
to wake up the first task each time the robin goes 'round.  It isn't
quite as efficient as I had planned, but what I want to test is 
task-relative anyway, not real-time sensitive.  Any problems with this?
_____        
  |      Todd M. Lewis            Disclaimer: If you want my employer's
  ||\/|  utoddl@ecsvax.uncecs.edu             ideas, you'll have to
  ||  || utoddl@ecsvax.bitnet, @unc.bitnet    _buy_ them. 
   |  || utoddl@next1.mscre.unc.edu 
       |___   ("Prgrms wtht cmmnts r lk sntncs wtht vwls." --TML)