fdr@swan.ulowell.edu (Franklin Reynolds) (10/27/88)
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
eugene@eos.arc.nasa.gov (Eugene Miya) (10/28/88)
See latest (Oct) issue of Computer (IEEE).
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."tvf@cs.rochester.edu (Thomas V. Frauenhofer) (11/01/88)
In article <5276@saturn.ucsc.edu> masscomp!fdr@swan.ulowell.edu (Franklin Reynolds) writes: > >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? Indeed, there are 2 "strains" of real-time systems: hard and soft. Hard real-time systems are what you define; soft real-time systems allow for some deadlines to be missed (within some error range) as long as missing a deadline will allow the overall system time specifications to be close. Remember, time deadlines are the raison d'etra of real-time systems. We want guaranteed, repeatable performance every time. > >Another thing about most real time research is that most people seem to >treat deadlines as all or nothing situations. Depends on what are the results of missing a deadline. Some are fatal; some aren't. You might want to leaf through the proceedings of the IEEE Conferences on Real-Time Systems. >Franklin Reynolds >harvard!masscomp!fdr >fdr@masscomp.uucp -- Another musing from: Tom Frauenhofer ...!rutgers!rochester!kodak!bmt!tvf or send mail to ...!rutgers!rochester!rit!anna!ma!tvf1477 BLOOM: You can't kill the actors! They're human beings! BIALYSTOCK: Oh yeah? You ever eat with one?
fdr@swan.ulowell.edu (Franklin Reynolds) (11/04/88)
In article <5331@saturn.ucsc.edu> (Thomas V. Frauenhofer) writes: > >Remember, time deadlines are the raison d'etra of real-time systems. We want >guaranteed, repeatable performance every time. > I certainly agree that time constraints are the uniquely identifying characteristic of realtime systems. However, I contend that guaranteed, repeatable performance means different things in different situations. If we are discussing a realtime application that controls a high performance disk controller it is not unreasonable to believe that the system can designed so that all of the demands on it can be met. This is one type of guaranteed behavior. If we are talking about a distributed control application running a large factory full of robots then we have to deal with aperiodic and unpredictable work loads. In this case, "guaranteed, repeatable performance" means dealing with the overload condition in a guaranteed and repeatable manner. Presummably the most important things are allowed to meet their time constrants while the least important things are discarded. I feel that simple, embedded systems with periodic or at least predictable demands are fairly well understood. I am much more interested of large distributed systems. Unfortunately most of the research seems oriented towards the former, rather than the latter problem. >> >>Another thing about most real time research is that most people seem to >>treat deadlines as all or nothing situations. > >Depends on what are the results of missing a deadline. Some are fatal; some >aren't. > Right. But what is lacking is a good way for the programmer to express "soft deadlines" and the value to the system associated with them. How does the programmer tell the scheduler that a process has residual value even though its deadline has been missed? How does the programmer tell the scheduler the rate at which the process loses value once it has missed its deadline. What if the rate it loses value is not constant? Most (all ?) deadline scheduling systems starve the threads with soft deadlines regardless of the value to the system the soft deadline process. That might sound reasonable, but what if the process with the soft deadline acquires some resource that a hard deadline process needs? If the soft deadline process is starved then any dependent hard deadline processes will miss their deadlines. >You might want to leaf through the proceedings of the IEEE Conferences on >Real-Time Systems. > I have. But usually there are only a few papers on scheduling. Not only is the small number of papers a drag but the majority of those deal exclusively with hard deadlines and non-overload conditions. Franklin Reynolds harvard!masscomp!fdr fdr@masscomp.uucp