NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/realtime/1557

Internet Message Format | 1993-01-12 | 4.5 KB

Path: sparky!uunet!mcsun!uknet!newcastle.ac.uk!warton!naw2
From: [e-mail] (Adrian Waterworth)
Newsgroups: comp.realtime
Subject: Re: novel idea?
Message-ID: <[e-mail]>
Date: 12 Jan 93 09:10:05 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: University of Newcastle upon Tyne, UK, NE1 7RU
Lines: 79
Nntp-Posting-Host: warton

[e-mail] (Dave Bruce) writes:

>In article <[e-mail]>, [e-mail] (Adrian Waterworth) writes:
>|> [e-mail] (Peter Moylan) writes:
>|>
>|> >In article <[e-mail]>, [e-mail] (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 : [e-mail]
                 UUCP : ...!uknet!newcastle.ac.uk!Adrian.Waterworth
PHONE : [phone]
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.