Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!agate!shelby!rutgers!cbmvax!rsbx From: rsbx@cbmvax.commodore.com (Raymond S. Brand) Newsgroups: comp.sys.amiga.tech Subject: Re: Task Switching Problem Message-ID: <14906@cbmvax.commodore.com> Date: 5 Oct 90 14:10:09 GMT References: <1990Sep21.180100.28580@uncecs.edu> <14593@cbmvax.commodore.com> <14900@cbmvax.commodore.com> Organization: Commodore-Amiga Inc, West Chester, PA Lines: 70 In article <14900@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > 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. [...] > 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. Actually, all timer.device functions can be used at any time, including inside interrupt and exception handling code. However, to get the accuracy you need, you'll need to use the 2.0 timer.device GetEClock library entry-point. > 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. This is actually easy when you have both timers and only mildly anoying when you only have one time. > 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. This probably isn't a problem since the amount of time spent handling interrupts is small compared to the quantum. However, there is another problem, exec reschedules the tasks after interrupts. So in practice, the time spent handling interrupts and your task timing functions could be of comparable size to the time spent actually executing the task code. > > 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 rsbx ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "Looking" ------------------------------------------------------------------------