home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.realtime
- Path: sparky!uunet!psinntp!sunic!ugle.unit.no!ugle.unit.no!ojr
- From: ojr@itk.unit.no (Ornulf Rodseth)
- Subject: Re: novel idea?
- In-Reply-To: genillou@litsun.epfl.ch's message of 11 Jan 93 10:12:32 GMT
- Message-ID: <OJR.93Jan12093949@mons.itk.unit.no>
- Lines: 31
- Sender: news@ugle.unit.no (NetNews Administrator)
- Organization: Norwegian Institute of Technology / SINTEF, Trondheim, Norway
- References: <erempel.726720401@sol.UVic.CA> <5620@disuns2.epfl.ch>
- Date: 12 Jan 93 09:39:49
- Lines: 35
-
-
- In article <5620@disuns2.epfl.ch> genillou@litsun.epfl.ch (Guy Genilloud) writes:
- > |> ...
- > |> I am looking for an OS (real time obviously) that has the
- > |> ability to swap a task from one cpu to another. This is merely
- > |> ...
- > |> Evan Rempel
- > |> erempel@sol.uvic.ca
- >
- > If the CPUs are different, it is more appropriate to speak of migrating objects
- > than to speak of swapping tasks. Look for papers on distributed systems and
- > migration for ideas on this subject.
- > ...
- > Guy Genilloud
- > EPF Lausanne, Switzerland
-
- It should be relatively easy to generalize this in an event-driven
- system. In such systems all state should (in principle) be explicitly
- represented in "state variables". Further more, all processing and
- state changes are initiated by events.
-
- You need a way to transfer state from one CPU to another in an
- architecture-independent way (e.g., XDR) and you need two or more
- identical set of event handlers (i.e., tasks), each compiled for its
- own CPU.
-
- As long as you keep the state in sync and switch tasks at
- event-arrival boundaries you should be just fine.
-
-
-
- --
- Ornulf Jan Rodseth M.Sc. ojr@itk.unit.no
- SINTEF Automatic Control +(47 7) 594351 (direct) / 594375 (switchboard)
- N-7034 TRONDHEIM, NORWAY +(47 7) 594399 (fax)
-