[Timber] bug (?) in ASYNC implementation

[Ivan Tarasov]

Andrey, Per, Johan,

thank you for your replies. I'm not an expert on real-time systems and
scheduling yet, and I haven't had a chance to encounter these topics
while studying at the university, so please forgive me if I'm being a
bit thick.

I would need to think about that problem some more (and probably try
to design some real-time application in Timber before I make my mind),
however so far I have a bad gut feeling about giving the principle B
priority over A. One of the reasons for this is that (it seems to me
that) it is harder to reason about the system behavior if the
baselines and (later) deadlines may drift in case of execution window
overlaps. I understand that this is not an expected "normal" state for
the system to schedule some action with a deadline in the past,
however it is not hard to imagine that happening and its consequences
should be taken into account during the application design.

Also, there is a (perceived) inconsistency: I'd expect a baseline of 0
to be the equivalent to an inherited baseline (by continuity), however
it differs in that special case when we're past the baseline in time;
unless you know exactly the relation between (now-currentBaseline) and
the new baseline, so there's now way to tell how the baseline is going
to be set unless you know exactly what (now-currentBaseline) is. By
continuity I mean the continuity of the difference of the intended
baseline value and actual baseline value when intended baseline tends
to 0.

I don't really buy the argument that it leads to a less rigid system:
that choice (rigidity vs laxity) should be explicit and available to
the developer, not implicit. Any choice of these two may be considered
as arbitrary.

I'm not sure I understand how to express non-deterministic timing in
current design (except for the case where by non-determinism here is
meant to be caused by non-deterministic execution duration of the code
which schedules new action). Why would one want to do that? Even if
one does, isn't it better to provide an alternative which is separate
from the scheduling mechanism?

Regards,
Ivan

2009/10/26 Johan Nordlander <johan.nordlander at ltu.se>:
> Timing in Timber relies on two principles:
>
> A: the baseline of an action is independent of the time when the action was
> called.
> B: the timing of any computation is correct as long as it occurs within its
> designated execution window.
>
> However, when the desired execution window for a called action overlaps with
> the execution window of the caller these principles clash, as some
> executions that are perfectly valid according to principle B might
> nevertheless lead to timing constraints for the callee that are impossible
> to met according to A.
>
> The clash can be resolved by giving principle B priority over A (the current
> Timber choice) or giving A priority over B (the choice described in
> "Programming with Time-Constrained Reactions").  Per and Andrey are right in
> describing the issue as not finally settled, but there are a few good
> arguments in favor of giving priority to principle B:
>
> - It leads to systems that are less rigid in the presence of dynamic
> overload.
> - It gives the programmer an option to actually express non-deterministic
> timing if desired.
> - It still allows completely deterministic timing whenever the execution
> windows of caller and callee don't overlap, and the programmer is always
> free to ensure this is the case.
>
> Hope this clarifies the reasons for the current design.  Still, examples
> where a different design would seem more appropriate are most welcome!
>
> -- Johan