Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!bionet!ames!saturn!marcel
From: marcel@saturn.ADS.COM (Marcel Schoppers)
Newsgroups: comp.realtime
Subject: Re: Why concurrency in real-time systems design?
Message-ID: <11123@saturn.ADS.COM>
Date: 5 Mar 90 18:09:48 GMT
References: <1990Mar2.122113.2196@irisa.fr>
Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300
Lines: 22


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