Article View: comp.sys.amiga.tech
Article #5620Re: Task Switching Problem
From: Todd M. Lewis
Date: Thu, 04 Oct 1990 19:53
Date: Thu, 04 Oct 1990 19:53
41 lines
2721 bytes
2721 bytes
In article <14782@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes:
>
>Yes. You're missing the point. Signal/Wait are for synchronizing on event
>occurances. The round-robin loop around is not an appropriate event to
>synchronize on.
I sorta had a bad feeling about doing that anyway. It would
probably serve my purposes in this case, but it isn't a general
solution to the problem.
>Tell me what you want to do, and I'll show you the proper method/algorithm
>to do it.
Now, if I could hold you to that for about 20 years, my job would
be a lot easier! :-) I assume you mean for this particular problem.
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. The process I'm modeling is perfectly simulated by the
round-robin run-if-ready scheduling that exec is already doing. I'd hate
to have to rebuild all that just to get a count of time-slices used
by each task. Note that the number of times a task has been awakened
from a Wait() is not enough--I also need the number of slices consumed
in the calc part (which can be quite a few).
I would prefer to use the "proper" way to get this info, if there is one.
>Valentin
_____
| 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)
Technical Details
Message-ID:
<1990Oct4.195348.8975@uncecs.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!mephisto!mcnc!ecsgate!ecsvax!utoddlReferences:
<1990Sep21.180100.28580@uncecs.edu> <14593@cbmvax.commodore.com> <14782@cbmvax.commodore.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!mephisto!mcnc!ecsgate!ecsvax!utoddl From: utoddl@uncecs.edu (Todd M. Lewis) Newsgroups: comp.sys.amiga.tech Subject: Re: Task Switching Problem Message-ID: <1990Oct4.195348.8975@uncecs.edu> Date: 4 Oct 90 19:53:48 GMT References: <1990Sep21.180100.28580@uncecs.edu> <14593@cbmvax.commodore.com> <14782@cbmvax.commodore.com> Organization: UNC Educational Computing Service Lines: 41