From: Adrian.Waterworth@newcastle.ac.uk (Adrian Waterworth)
Newsgroups: comp.realtime
Subject: Re: novel idea?
Date: 12 Jan 93 09:10:05 GMT
Organization: University of Newcastle upon Tyne, UK, NE1 7RU

dbruce@ll.mit.edu (Dave Bruce) writes:

>In article <C0onL4.2qE@newcastle.ac.uk>, Adrian.Waterworth@newcastle.ac.uk (Adrian Waterworth) writes:
>|> eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
>|> 
>|> >In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
>|> >> 
>|> >> running on the side for complex graphics. If the i860 becomes
>|> >> bogged down (I don't know what I would be doing to bog down the
>|> >> i860, but lets say I do) and the 68040 is sitting idle (or close
>|> >> to it) can one of the tasks that is running on the i860 be switched
>|> >> over to the 68040 to run there.
>|> >> 
>|> 
>|> >You must be joking.  The machine languages of these two processors
>|> >are totally different.  Would you plan to run an 860 simulator on
>|>
>|>	...
>|> 
>|> available, what's wrong with having two _pre-compiled_ versions of the
>|> task (one for each processor)? The task switching problem then becomes
>|>
>|>	... 

>I think the original author of this article wants the 68040 to take over
>execution of a task that has been started but is being starved of cpu time.
>And since the 68040 is twiddling its thumbs, it can give some help. If there
>are two (or more) _pre-compiled_ versions of a task, what about the present
>state of the task(s)? Globals, stacks, task allocated resources need to
>transferred over to architecturely different cpu. I agree with Peter, "You
>Must Be Joking!"

	As other people have already mentioned, this is not such a
great problem. It's just a case of having an appropriate representation
of the required state information (e.g. using implementations based
upon p-code, as someone already suggested, or something based upon an
abstract notation like ASN.1) to allow the copy of the task on the
lightly-loaded processor to pick up the appropriate data and values
from the copy that was running on the heavily-loaded one. In a
multi-processor environment (non-distributed), the availability of
shared memory areas and/or relatively high bandwidth interprocessor
communication mechanisms (e.g. via backplane) may make this a feasible
approach to adopt. The distributed case is then more interesting
because you may find yourself in the position of having to ship values
(encoded or otherwise) around a network. However, you also end up
having to ship values around a network in the homogeneous distributed
case and, although the cross-architectural encoding aspect of the
problem can be largely ignored, some degree of encoding of the internal
state will usually be required to allow transmission across the
network. (And I know that this problem has been addressed and
appropriate migration mechanisms implemented in some cases - e.g. the
object mobility mechanisms found in the Emerald language/system.)

	At the end of the day, it all boils down to the amount of
internal state information held by a task and the efficiency of
implementation of state transfer. If a task has a small amount of
internal state information, arranging for the transfer of that
information, in an appropriate format, to another task might be fairly
straight-forward. On the other hand, if a task has vast amounts of
internal state information, then the transfer will not be so easy.
(Although, in the latter case, I begin to wonder about the
implementation of the task itself - if it does have vast amounts of
internal state information then maybe it should not be a single task at
all but should be further decomposed into sub-tasks, accessing a common
information base in a suitably controlled manner? On the other hand,
can anyone think of a task that does require large amounts of internal
state in order to execute and that cannot be further decomposed?)

			Cheers,
				Adrian.

_______________________________________________________________________________
FROM  : Adrian Waterworth.   E-MAIL : Adrian.Waterworth@newcastle.ac.uk
			     UUCP : ...!uknet!newcastle.ac.uk!Adrian.Waterworth
PHONE : +44 91 222 6858
POST  : DCSC, Department of Computing Science,
	University of Newcastle upon Tyne, UK. NE1 7RU.

DISCLAIMER : I only work here - any opinions expressed are my own.
Newsgroups: comp.realtime