Re: Interresting thread in comp.lang.eiffel

["Ken Garlington" <Ken.Garlington@computer.org>]

"David Gillon" <david.gillon@baesystems.com> wrote in message
news:396DA53D.19DDBACE@baesystems.com...
>
>
> David Gillon wrote:
>
> > One thing I'm still waiting to hear in this discussion is how Eiffel
> > would handle a temporal constraint of the type 'Signal A will be updated
> > with its new value within 2.5 ms of a change to any of its source
> > inputs'.
>
> Blast, I meant to ask how DBC would handle than kind of constraint, not
> Eiffel specifically.

Well, it depends upon whether you mean "handle" in a run-time sense, or
"handle" in an analytical sense.

The particular description you gave could be interpreted as a thread-level
constraint, not a module-level constraint (if "source input" means a system
input, not a module input). Thread-level analysis tend to be the more
interesting ones, so I'm assuming this is what you meant. There are
certainly analysis techniques to do this, from which you can derive
module-level maximum run-times. (Of course, these run-times will have to be
the worst-case, unless the module has some way to know in what thread it is
currently participating.) You could then use these module-level constraints
in future thread-level analyses.

Coding these into the module as a run-time check might be tricky, since you
probably want only the time the module is actually running, not the time
between the start and end, but it's possible. There are some likely adverse
effects of doing so, such as reusability. Assuming you use some standard
scheduling technique (RMS, EDF) to enforce the assumptions of your
thread-level analysis, you can alternately have your scheduler detect
violations of that analysis at run-time. As a practical matter, it's
probably much preferable to do the temporal run-time checks in the
scheduler.