Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!ames!uhccux!munnari.oz.au!cluster!metro!ipso!runxtsa!jon
From: jon@runxtsa.runx.oz.au (Jonathon Seymour)
Newsgroups: comp.realtime
Subject: Re: Why concurrency in real-time systems design?
Summary: concurrency decouples activities with different time constraints
Message-ID: <742@runxtsa.runx.oz.au>
Date: 7 Mar 90 10:05:05 GMT
References: <1990Mar1.152922.1005@axion.bt.co.uk>
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 53



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.