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

Text File | 1993-01-12 | 3.7 KB | 81 lines

Newsgroups: comp.realtime
Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!news.u-tokyo.ac.jp!ccut!s.u-tokyo!is.s.u-tokyo!jeff
From: [e-mail] (Jeff McAffer)
Subject: Re: novel idea?
References: <[e-mail]>
    <[e-mail]> <[e-mail]>
Nntp-Posting-Host: water
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Organization: University of Tokyo / Object Technology International
In-Reply-To: [e-mail]'s message of 11 Jan 93
    09:27:03 GMT
Sender: [e-mail] (Usenet News System)
Date: Tue, 12 Jan 1993 08:44:45 GMT
X-Bytes: 3081
Lines: 64

In article <[e-mail]> [e-mail] (Adrian Waterworth) writes:

 >      I'm not sure that I entirely agree. In particular, why should
 >it be necessary "to re-compile the source code each time you switched
 >processors"? Assuming that enough memory or on-line storage is
 >available, what's wrong with having two _pre-compiled_ versions of the
 >task (one for each processor)? The task switching problem then becomes
 >a simple case of suspending on one processor and loading/running on the
 >other. I can't think of any references straight off the top of my head,
 >but I know that this kind of technique has long been proposed (and
 >probably used by now) as a means of supporting load-balancing and
 >process migration in heterogeneous distributed systems.

Several people have expressed ideas similar to this.  That is, have
the same source compiled for all the different machines and just task
switch.  I agree that this will work but it is too particular a solution.

It would be better to look at the bigger picture.  For instance, from
the Client/Server view, some service is being asked for.  The i860 is
in the middle of supplying the service and we decide that it would be
better done on the 040 (for whatever reason).  In a general (read
heterogenous) computing environment, the 040 not only has different
instruction codes but may also have a different memory architecture,
OS, software (application) structure...

Since we are going to switch the task to the 040 we assume that the
040 can supply the required service.  There is no strict requirement
for it to provide it with the same task recompiled for a different
machine.  In fact, there is no real requirement that it even supply
the service in the same way (implementationally).  In fact, it need
not even supply the service at all!  I just needs to know how to get
the service done.  That may mean shipping it off to yet another
processor.  Who knows.  All we need to know is that it can do it and
it will cost X to get it going.

The factors involved are:

1) saving work already done before the switch (not necessary but may
be nice)

2) in cooperation with #1, a finer granularity of services (tasks) so
we can continue a service given the intermediate results.

3) deciding when it will be better to switch a task to another
machine.

4) determining appropriate service (task) on the target machine to use
to continue the task.  This may even require the starting of a new
task on the target.

#3 is the most difficult.  You need some way of measuring the costs of
both switching and not switching.  if the ratio is less than 1 then a
switch would help.  You may require it to be < 0.8 of something before
switching.

Rather than striving for homogeneity at the compiled (machine, p,
byte...) code level or a direct and identity mapping amongst tasks in
a system we should be looking for consistency and generality at the
task/service level.  A task is a task is a task.  If it does what you
want, use it!

--
ato de, |m        -- spice is the irony of life!   thks mm