Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bagate!cbmvax!rsbx
From: rsbx@cbmvax.commodore.com (Raymond S. Brand)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Task Switching Problem
Summary: correction and more information
Message-ID: <14930@cbmvax.commodore.com>
Date: 7 Oct 90 18:15:51 GMT
References: <1990Sep21.180100.28580@uncecs.edu> <14593@cbmvax.commodore.com> <14906@cbmvax.commodore.com>
Organization: Commodore-Amiga Inc, West Chester, PA
Lines: 26

In article <14906@cbmvax.commodore.com>, rsbx@cbmvax.commodore.com (Raymond S. Brand) writes:
> 
> 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 scheduler in the 2.0 exec has been fixed so that it nolonger reschedules
tasks when it doesn't need to. 1.3, however, still has the problem. :-(

What was happening is that anytime the internal AddTask, Permit, or Signal
functions were called (mostly by the external functions of the same name),
a reschedule happened. Signal is used by a number of interrupt handlers and
servers, either directly or indirectly through passing messages.

> 						rsbx

						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"
------------------------------------------------------------------------