rdoyle@axion.bt.co.uk (Number Six) (03/01/90)
Another question for all you real-time experts... Can anyone give me any ideas/references on why you need to use concurrent tasks in the design of real-time systems? I am perfectly willing to accept arguments based on purely pragmatic reasons (eg "Past experience shows this is the best way"), but I would be interested to hear any fundamental justifications that this is the way we should model the design of any real-time system. (Please note that I am not assuming a concurrent hardware architecture - the design could, for example, be implemented on a single processor). Thanks Richard Doyle -- Carpenter from Nazareth, seeks joiners.
dstewart@fas.ri.cmu.edu (David B Stewart) (03/02/90)
In article <1990Mar1.152922.1005@axion.bt.co.uk> rdoyle@axion.bt.co.uk (Richard Doyle) writes: > > Another question for all you real-time experts... > > Can anyone give me any ideas/references on why you need >to use concurrent tasks in the design of real-time systems? That's a simple question to answer: We use concurrency for logical division of tasks. The easiest way to solve a big problem is to solve lots of little problems, and then put all the results together. When programming such a problem, each little problem can be made a separate task which runs concurrently. Another reason it is required is when there are multiple resources that have to be used, with the possibility of blocking while waiting for a resource. In a system using a single-tasking OS, a program waiting for input could not do something else at the same time. In a concurrent environment, one task could be waiting for input, while another is doing something completely different. As systems become more complex, this becomes a necessity. Thirdly, the timing requirements for a system are often too complex to specify as a single non-concurrent program, especially if the timing requirements are variable. To give you an example, we have a real-time system controlling our robot. The robot has six position sensors, a force sensor, a camera, a tactile sensor, a gripper, and both a joystick and the keyboard for input. It is possible to use only some of these at any one time. The most logical way to separate things is to have one task controlling the output signals to the robot; another reading the position sensors, another reading the force sensor, another reading the camera, etc. If we decide we only want to use the force sensor, and not the camera nor the tactile sensor, then it is simply a matter of only starting up the tasks we want, with no need to change any code. You might say, "Why not just put flags in, `if (using camera) do this', but that would not work. The camera works at 30 Hz; the force sensor at 400Hz, the robot and position sensors at 1000Hz, the joystick at 25Hz, and the tactile sensor at 120Hz. How can that be encoded into a single program? It becomes extremely difficult to write a single program with no concurrency that can have so many different time frames. It is even more difficult (if not impossible) if some of those frequencies can be varying (e.g. the robot can be slowed down to 200Hz). By using a concurrent environment, each different time frame is in a different task, thus the frequency of each task can be specified separately, and the burden of deciding what to run when is placed on the operating system. Even if the timing changes, there is no need to reprogram anything, the real-time operating system should be capable of adapting to the new requirements. If a non-concurrent program was used, the entire program would have to be restructured in order to satisfy the new timing requirements, hencing making even the slightest change an immense amount of work. And of course, when you start worrying about non-periodic events, the programming of a real-time system to perform under specific timing constraints cannot even be perceived (at least not by me). I am sure there are a million other reasons why concurrency is necessary in real-time systems, but I am sure the above examples will at least provide a good idea why it is required. ~dave -- David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, Carnegie Mellon University, email: stewart@faraday.ece.cmu.edu The following software is now available; ask me for details CHIMERA II, A Real-time OS for Sensor-Based Control Applications
schang@netcom.UUCP (Sehyo Chang) (03/02/90)
In article <1990Mar1.152922.1005@axion.bt.co.uk> rdoyle@axion.bt.co.uk (Number Six) writes: > > Another question for all you real-time experts... > > Can anyone give me any ideas/references on why you need >to use concurrent tasks in the design of real-time systems? >I am perfectly willing to accept arguments based on purely >pragmatic reasons (eg "Past experience shows this is the >best way"), but I would be interested to hear any fundamental >justifications that this is the way we should model the design >of any real-time system. > > (Please note that I am not assuming a concurrent hardware >architecture - the design could, for example, be implemented >on a single processor). > Richard Doyle > >-- Simple, it is easier to design natural world with concurrent system than with serial design (even if you do everything in one processor, then you want to parallel-serial transformer or time slice scheduler). Summarize you want(and should) do concurrent design for you real time system because (1) multiple concurrent system gives better performance than a single processor. It is easier to distribute load among concurrent processes for time-critical event (2) concurrent design are easier than serial design in addition to the fact much of system specification/design can be only done in concurrently!!. -- Sehyo Chang schang@netcom.uucp Ascent Logic Corp. (408)943-0630
rks@kurki.tut.fi (Kurki-Suonio Reino) (03/02/90)
In article <1990Mar1.152922.1005@axion.bt.co.uk> rdoyle@axion.bt.co.uk (Number Six) writes: > > Can anyone give me any ideas/references on why you need >to use concurrent tasks in the design of real-time systems? Concurrency is inherent in reactive systems - real-time or not, implemented on single or multiple processors, and irrespective of efficiency considerations - since the environment works concurrently with the reactive system itself. Reino Kurki-Suonio
leguerni@irisa.irisa.fr (Paul Le Guernic) (03/02/90)
From article <1990Mar1.152922.1005@axion.bt.co.uk>, by rdoyle@axion.bt.co.uk (Number Six): > > Can anyone give me any ideas/references on why you need > to use concurrent tasks in the design of real-time systems? I see two different questions in the above one. 1. Why to use concurrent tasks to design real-time application ? The answer was given by David B. Stewart : just because a real time system interacts with concurrent external tasks. 2. Is it necessary to implement it with concurrent tasks (activation, interruptions, priorities,...) ? -If online changes to the system may occurs, it is necessary to be able to suppress and create tasks. -If you want to build a single task (automaton), you have to build it by some product of simpler automata; this work is analogous to removing procedure calls. First of all, because of its complexity, you need a compiler to do it; but even if such a compiler is available, this product of automata may result in an exponential (even if finite) expansion of memory; then you need system functions to handle more than one automaton (tasks). Nevertheless, most of real time system could be built with a very small subset of task handling structures.
marcel@saturn.ADS.COM (Marcel Schoppers) (03/06/90)
If by concurrency is meant the use of parallel hardware, then its use may be a matter of real response time -- more processing power permits faster response. If we are talking about pseudo-concurrency only, i.e. whether or not to use time-slicing on a fixed amount of hardware, then real response time is not the issue: pseudo-concurrency can be good software engineering. As mentioned by the previous message from IRISA (referenced above), one builds complex machines by composing simpler machines; dispersing functionality across processes/tasks is like splitting software into procedures, and if done properly, can reduce the complexity of the program -- each process/task gets to monitor fewer aspects of the domain/plant, with interactions between processes/tasks being called out explicitly. Beyond that advantage, though, pseudo-concurrency creates the possibility of off-loading preemption and scheduling decisions from the user's code to the scheduler, another plus for program clarity. I think it safe to say that pseudo-concurrency is purely a software complexity management technique, and has nothing whatever to do with system performance (since you could also control your program's execution by scattering branches, jumps, and polling throughout your code). Marcel Schoppers
jon@runxtsa.runx.oz.au (Jonathon Seymour) (03/07/90)
Probably the best reason to use concurrency in real time systems is to decouple parts of the system which have different time constraints. For example: consider a plant controller which in addition to controlling some sort of mechanical plant must perform plant modelling, data reduction and user interface management. The control interval might be 1/20th of a second. The modelling interval might be a second and consume 0.3 seconds of CPU time. Data reduction might be performed once every 5 minutes but may consume 10 seconds of CPU time. Finally, the user interface could be inactive for long periods of time but require fast response times (1/2 - 1 second) when used. Humour me for the moment and suppose that you were going to implement this system with a straight sequential program - no interrupts, just a control loop. Clearly the body of the control loop would have to execute in at most 0.05 seconds to support the control interval specification. This is going to really complicate the implementation of the slower activities such as data reduction and user interface management as these activities will have to be broken into sub 0.05 second chunks. Ugly. Of course, you could use interrupt routines to alleviate the hard time contraints on the main control loop, but even then how would you provide a fast response time to the user if the program was in the middle of a 10 second data reduction? Interrupts again? Mmmm...once again things are starting to look messy. In any case, if you are using interrupts you are really writing a concurrent program. Consider the truly concurrent solution: one task each for plant control, modelling, data reduction and user interface management. Assign appropriate priorities to each and let the kernel work out how to schedule the activities. The result - clean, reliable and easily maintainable code. The only problem with a truly concurrent solution on a conventional single processor is the cost of a context switch. This cost forces the re-introduction of interrupt routines to satisfy the harder time constraints. However, the softer time constraints of the slower tasks can still be met with true concurrent techniques. jon. References: Niklaus Wirth, "Toward a discipline of Real-Time Programming", in Communications of the ACM, August 1977, Vol 20, No 8. In this article Wirth characterises real-time applications as those in which the system must respond to the environment within a finite time or else synchronisation with the environment will fail.
gertner@Encore.COM (Ilya Gertner) (03/22/90)
In article <742@runxtsa.runx.oz.au> jon@runxtsa.runx.oz.au (Jonathon Seymour) writes: > > >Probably the best reason to use concurrency in real time systems is >to decouple parts of the system which have different time constraints. > very interesting... could the same argument be used for IPCs in real-time systems: some events are handled as emergencies, with preemption, other's could be queued for sychronous (send/receive) handling. How does it sound from both theoretical (i.e. starting from scratch) and practical (need to coexists with the dusty-deck) points of view? Ilya