Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!varvel From: varvel@cs.utexas.edu (Donald A. Varvel) Newsgroups: comp.realtime Subject: Re: What makes a system "real-time?" (Was: Real-Time references wanted) Message-ID: <7060@cs.utexas.edu> Date: 18 Oct 89 20:03:26 GMT References: <1989Oct18.151758.5227@planck.uucp> <89291.133937UH2@PSUVM.BITNET> Organization: U. Texas CS Dept., Austin, Texas Lines: 43 In article <89291.133937UH2@PSUVM.BITNET> UH2@PSUVM.BITNET (Lee Sailer) writes: :I've seen two different meanings assigned to "real-time." In corporate data :precessing circles, it often just means something like "pretty fast" or :"as fast as a person needs it to be." For example, a database might be :"real-time" is the user gets the results of a query within a few seconds of :hitting the key. While non-hard (soft?) real-time is often much better defined than this, the above describes a segment of the field. :In cases where software is an integral part of some hardware, "real-time" :means that certain actions are guaranteed to complete within some known :amount of time. This sounds like our working definition of ``hard real-time''. Deadlines exist, and must be met. Either we can guarantee that at design time or a correct system cannot be designed. :In this case, you could write software to do things like controlling the :flaps of your space shuttle (isn't everyone working on one?) without :worrying about whether the flap-controller might get swapped out at a bad :time. : :It gets more complicated than this, because there can be multiple layers :of guarantee, and so on. I'm confused. Are guarantees not guarantees? ``Oh, but flap-controller response isn't guaranteed at this level. We are sorry about your airplane, but our design met the specifications at every level.'' Guaranteed timeliness of low-level operations can be used to guarantee the timeliness of higher-level operations, if that's the point. :I like the previous responders generic defintion that a real-time system :is one where an operation must complete within a certain specified time or :else it is an error. I like the previous responder's definition also, in that it includes my work but not much of the rest of the field. I see it as excluding correct real-time implementations of anything that interacts with an unpredictable environment, since sensory overload is possible in nearly any such system. Am I misinterpreting the definition? -- Don Varvel (varvel@cs.utexas.edu)