Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!fas.ri.cmu.edu!dstewart
From: dstewart@fas.ri.cmu.edu (David B Stewart)
Newsgroups: comp.realtime
Subject: Re: Why concurrency in real-time systems design?
Message-ID: <8240@pt.cs.cmu.edu>
Date: 1 Mar 90 19:25:35 GMT
References: <1990Mar1.152922.1005@axion.bt.co.uk>
Organization: Carnegie-Mellon University, CS/RI
Lines: 71

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