Path: utzoo!attcan!uunet!lll-winken!decwrl!shelby!rutgers!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!+ From: David.Maynard@CS.CMU.EDU Newsgroups: comp.realtime Subject: Re: Software primitives for real-time programming languages Message-ID: Date: 25 Sep 90 16:52:38 GMT References: <12682@cs.utexas.edu> <1844@tuvie> <224@srchtec.UUCP>, <1853@tuvie> Organization: Carnegie Mellon, Pittsburgh, PA Lines: 74 In-Reply-To: <1853@tuvie> > It precludes everything for which you can not give a-priori guarantees > that the system will meet its timing constraints under all foreseeable > circumstances and no more. This is what hard real-time systems are for. If this is supposed to be a discussion of software primitives for real-time programming in general, then I see no reason to limit the discussion to primitives that only support so-called "hard real-time systems." There is a HUGE body of real-time applications with (at least some) stringent timeliness requirements that do not fit in the mold of "hard deadlines that can never be missed." In the past, designers have had to force-fit these applications into rigid systems that divide the universe into hard deadline tasks and background jobs. If we are really interested in improving the state-of-the-art for real time systems, then why don't we discuss programming primitives that will help application designers describe their REAL requirements. Then maybe we can concentrate OS and scheduling research efforts in areas that will actually be of some benefit. > >To broaden the horizon of this particular discussion thread: stochastic > >behavior of some tasks .... > But then you have to live with the fact that your system will fail from > time > to time. ... No, you have to live with the fact that the world isn't deterministic -- and respond accordingly. As systems become larger and more complex it is becoming increasingly difficult to build working systems that assume everything is perfectly (at least in the worst case) predictable. A real solution to the real-time systems problem will embrace nondeterminism as a fact of life and will provide mechanisms for dealing with it. If an application has some vital low-level control loops that really require a certain level of determinism to ensure their stability, then the system will need to provide that level of service in spite of the fact that it is operating in an unpredictable world. The other components of the application, however, should be able to respond to unexpected events or failures in a more dynamic fashion. A major problem with much of the current real-time research is that people spend inordinant amounts of time doing the academic equivalent of saying, "I have a hammer. I'm going to make everything look like a nail." Just because we happen to have a solution that works on a limited class of problems doesn't mean that we should try to make other problems look "close enough" so that we can apply the solution we already know. We should be spending our time trying to develop solutions that address a larger class of problems from the outset. Alpha is an operating system (and the center of an ongoing research and development effort) that addresses many of these issues. Alpha is designed to support distributed real-time systems that may have a variety of stringent timeliness requirements. The application designer specifies these time constraints to the operating system using "time-value functions." Time-value functions express the value of completing an activity as a function of time. (Hard deadlines are described as a simple special case where the time-value function is a step-function.) As part of our research, we have developed (and continue to develop) a class of resource management algorithms that utilize time-value functions in the decision making process. I welcome a discussion of real-time specification methods (such as time-value functions) that allow you to express the real timeliness requirements of applications. There is definitely a need for more work in this area. However, I'm not interested in a discussion that assumes everything is a nail and tries to decide how long the nail is. -David Maynard --- David P. Maynard (dpm@cs.cmu.edu) Alpha OS Research Group Carnegie Mellon University & Concurrent Computer Corp. --- All opinions expressed are mine. I haven't asked CMU or Concurrent what they think. ---