Re: Need help with PowerPC/Ada and realtime tasking

[Richard Riehle <rriehle@nunic.nu.edu>]

On Sat, 18 May 1996, JP Thornley wrote:

> > This is very "hard" real time -- life critical application and
> > interrupts occurring at a frequency roughly 1/100 the speed of
> > the memory during peak situations (although most of the
> > time it is somewhat less frequently).
> >
>
> My first response is that safety-critical software does not go well
> with interrupts and the use of tasking.  The main requirement of
> safety-critical code is predictability, which is made impossible if
> you are coping with unpredictable interrupts and with hard-to-analyse
> tasking syncronisations.

  I would like to offer a slightly different view of this.

  The main requirement of safety-critical code is that it be "safe."
  The suggestion that a cyclic executive is safer than tasking is not
  necessarily true.  While predictability is essential, the important
  elemement of predictability is that the system is schedulable such
  that it can service all of its required tasks.

  A cyclic executive does not guarantee schedulability.  It does not even
  guarantee predictability.  In fact, a cyclic executive can guarantee
  that one actually fails to trap events as they occur.  An interrupt
  intelligent design can detect an interrupt and choose to ignore it,
  store it for later processing, etc.

  Using the Ada 95 tasking model, along with protected types, along with
  a healthy dose of rate-monotonic analysis, one can design an interrupt
  driven application that is predictable.

  While it is is true that the Ada 83 tasking model was somewhat frail
  in its range of options for effective interrupt-driven applications,
  especially in being able to guarantee schedulability, Ada 95 is a
  more robust model.

  The underlying problem, as usual, is designing an architecture that
  gurantees predictable schedulability.

  An additional problem with the cyclic executive model is ist lack of
  portability.  Since it is dependent on the timings of the platform to
  which it is targeted, it can fail to meet its goals when ported to a
  new platform.  With tasking, one is more dependent on the hardware-
  independent logic represented by the interaction of the tasks.  Again,
  the Ada 95 tasking model makes this fairly clean.

  Please do not think I am underestimating the difficulty of designing
  an architecture based on interrupt-driven protocol.  I am simply
  suggesting that Ada tasks should not be ruled out based on experience
  with the earlier Ada 83 design.  Also, I want to recommend a little
  caution in being too quick to believe that cyclic executives are any
  easier when one must depend on trapping interrupts in a timely
  fashion.

> I wouldn't expect to see anything other than a cyclic executive in
> safety-critical software.

  My note, above reflects my view on this.

> Have a look at Concurrency in Ada - Alan Burns, Andy Wellings,
> Cambridge University Press 1995, ISBN 0 521 41471 7, hardback

  I agree.  Except for a few minor syntactic errors, this is an
  excellent book.  Great exposition of protected types, and their
  role in object techonology.

> > The kinds of information/questions I have are:
> >
> > 1) What sorts of approaches do people use for tasking when
> >    the Ada tasking model is too slow?  How machine independent
> >    can these be?

  Tasking can be designed to be machine independent. As far as too
  slow, that is an issue which varies from compiler to compiler. It
  is also an issue that often originates in poorly design tasking
  architectures, misunderstaning of the rendezvous, and overall
  incorrect design.  For example, in an attempt to reduce the effect
  of tasking on a design, the software engineer sometimes uses too
  few tasks rather than too many.  In this case, each task is given
  too much work, and the system fails to meet its design goals.

  Ideally, the tasking environment is designed so each task spends most
  of its life waiting for something to do.  That way, it is always
  ready to do what it was assigned to do.  When I hear people say that
  tasking is too slow, and blame it on the compiler, or the RTE, I
  am inclined to ask for a closer look at the design.

  Don't underestimate the power of tasking.

> In safety-critical systems, predictability of operation comes first,
> second and third - factors such as speed and platform independence
> come a long way behind - in fact I don't see any way that you can
> qualify the system without defining the hardware it will be running
> on as software cannot be qualified on its own.

  Actually, this is one of the benefits of using tasking to define
  the architecture.  Remember that I speak here of Ada 95 tasking.

> > 2) What approaches can be used for sharing memory between
> >   processes that may or may not be located in the same processor
> >   (but the processors do have some shared memory and some
> >   local memory)

  An excellent example of this is the Silicon Graphics workstation. The
  way SGI has implemented tasking for sharing memory, processes, threads,
  etc. establishes that tasking is certainly useful for environments where
  performance and predictability are important.

  Richard Riehle