Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!saturn!masscomp!fdr@swan.ulowell.edu
From: masscomp!fdr@swan.ulowell.edu (Franklin Reynolds)
Newsgroups: comp.os.research
Subject: Real Time Operating Systems
Message-ID: <5276@saturn.ucsc.edu>
Date: 26 Oct 88 20:47:02 GMT
Sender: usenet@saturn.ucsc.edu
Organization: MASSCOMP - Westford, Ma
Lines: 41
Approved: comp-os-research@jupiter.ucsc.edu


A few months ago there was a brief discussion of real time
operating systems in this newsgroup (I think). I was interested
in the topic, but at the time I was employed by a company that 
strongly discouraged employees from posting to the net. I don't 
work there anymore. 

In an effort to start a discussion:

Several months ago Parnas published a paper in CACM that proposed
a new method for describing synchronization constraints for multiple
threads of control. I think the idea was to allow a programmer to 
specify a section of code and its relationship to another section of
code. Something like Section A can be executed as long as Section B
is not being executed. Complicated relationships as well as the number of
threads within a section could be specified. This seemed to me, like an 
elegant and expressive solution to an important class of concurrent
programming problems. Any comments?

Most of the research in real time that I have read about focuses on
trying to guarantee that all the deadlines can be met. This seems to 
me like trying to guarantee program correctness. It is a laudable,
though probably unabtainable goal, except in trivial cases. It seems to
me that when you start working on big problems, like the space station,
you have to assume that you will occasionally have overload conditions.
If this is true then you need a strategy that allows you to gracefully 
degrade in the face of overload. Comments?

Another thing about most real time research is that most people seem to
treat deadlines as all or nothing situations. It seems to me that there
are some computations that might have some value even if they do not
reach completion. Consider an expert system that has to deliver its advice
within a certain time frame. It might be useful to give the best advise
you can even if you could do a better job if you had more time. Game playing
programs do this sort of thing all the time. I think that scheduling 
computation that has value even though it does not meet its time constraint
is an interesting problem.

Franklin Reynolds
harvard!masscomp!fdr
fdr@masscomp.uucp