Because the baseline offset 50 ms is measured relative the current baseline at each invocation (and not the actual time of the recursive call), the implementation does not suffer from accumulating drift. (from Johan Nordlander, Mark P. Jones, Magnus Carlsson, and Jan Jonsson, Programming with Time-Constrained Reactions. Technical report, Luleå University of Technology, 2005.)

Andrey, thanks for pointing out that this is documented. Unfortunately I don't understand the reasons for introducing that special case. Particularly, from my understanding of the following: this special case breaks the requirement of not causing the newly scheduled actions to drift. Is there some other problem which this special case is intended to fix, which I don't recognize? Regards, Ivan 2009/10/26 Andrey Kruglyak :

From timber-lang.org >> Language summary >> Time constructs:

Time windows of reactions are assigned as follows:

The time window of a reaction to an external event has as baseline the time instant when the event occurs, and as deadline an idealised instant infinitely far into the future.

In particular, the start action of a program gets as baseline the time instant when program execution begins.

When a message without time constraints is sent (i.e., an plain action is called) from a method with current baseline bl and deadline dl, the reaction to the message inherits both bl and dl.

The rule in the previous item can be changed by explicit program constructs:

The expression after t act sets the effective baseline for act to the current baseline plus t.

The expression before t act sets the effective deadline for act to its effective baseline plust.

In both cases, act can be any expression of type Action, which includes the time-annotated constructs just introduced. Nested baseline offsets are composed using addition, while multiple deadline offsets are resolved by selecting the minimal value. The relative order of after and before constructs is not relevant.

Special case: if the baseline denoted by an after construct is an already passed time instant, the effective baseline of the reaction is rounded off to the actual time of the call.

Regards, Andrey On Oct 26, 2009, at 10:01, Ivan Tarasov wrote:

I'm trying to understand what constitutes an RTS and how a Timber program translated into C is actually executed. So, I'm reading the RTS implementations' code.

In rtsARM/rts.c, in ASYNC implementation, lines 439-442 we can see the following code:            if (LESS(m->baseline, now)) {                m->baseline = now;                // debug("^");            } Same code is present in ASYNC implementation in rtsPOSIX/rts.c, lines 354-355

That means that if the absolute time value for the baseline for the action to be scheduled is in the past, we set the baseline to the current time. However, since all the time calculations are relative to the baseline, that would mean that all the following actions to be scheduled from the one being scheduled at the moment would "drift". Is this an intended behavior? I'm not sure that's the right decision.

Ivan _______________________________________________ Timber mailing list Timber@haskell.org http://www.haskell.org/mailman/listinfo/timber

------------------------------------------------------------------------ Andrey Kruglyak PhD student http://www.andreykruglyak.com Dept. of Computer Science and Electrical Engineering Lulea University of Technology, Lulea, Sweden T +46 920 49 23 57 (office) T +46 706 16 76 03 (mobile) Office A2314 (A-huset) _______________________________________________ Timber mailing list Timber@haskell.org http://www.haskell.org/mailman/listinfo/timber

Hi Ivan You put the finger on a very interesting and import design feature, timing without drift. The permissible excecution window of a reaction is denoted by its absolute baseline and deadline. As long as the after constructs denotes specific points in time that are later (outside the permissible window), we will never suffer drift, as Andrey mentioned. If set inside the excecution window, it can actually be posted after its baseline is due, right. So what should the baseline be in that case, we have the choice to define the timing semantics such that the baseline and deadline to be inherited from the sender (and hence a deadline offset would extend the execution window beyond that of the senders. This is actually the "original" timing semantics. But this does not go well with the idea of the before construct as giving a relative offset to the release of the event. Anyways Ivan, your observation is perfectly valid, and I'm not sure we have seen the end of this "debate". In any case, as long as you keep after constructs outside your current execution window everything is fine and dandy. Best regards, Per On Oct 26, 2009, at 10:17 AM, Ivan Tarasov wrote:

Andrey,

thanks for pointing out that this is documented. Unfortunately I don't understand the reasons for introducing that special case.

...

Because the baseline offset 50 ms is measured relative the current baseline at each invocation (and not the actual time of the recursive call), the implementation does not suffer from accumulating drift. (from Johan Nordlander, Mark P. Jones, Magnus Carlsson, and Jan Jonsson, Programming with Time-Constrained Reactions. Technical report, Luleå University of Technology, 2005.)

Particularly, from my understanding of the following: this special case breaks the requirement of not causing the newly scheduled actions to drift.

Is there some other problem which this special case is intended to fix, which I don't recognize?

Regards, Ivan

2009/10/26 Andrey Kruglyak :

...

From timber-lang.org >> Language summary >> Time constructs:

Time windows of reactions are assigned as follows:

The time window of a reaction to an external event has as baseline the time instant when the event occurs, and as deadline an idealised instant infinitely far into the future.

In particular, the start action of a program gets as baseline the time instant when program execution begins.

When a message without time constraints is sent (i.e., an plain action is called) from a method with current baseline bl and deadline dl, the reaction to the message inherits both bl and dl.

The rule in the previous item can be changed by explicit program constructs:

The expression after t act sets the effective baseline for act to the current baseline plus t.

The expression before t act sets the effective deadline for act to its effective baseline plust.

In both cases, act can be any expression of type Action, which includes the time-annotated constructs just introduced. Nested baseline offsets are composed using addition, while multiple deadline offsets are resolved by selecting the minimal value. The relative order of after and before constructs is not relevant.

Special case: if the baseline denoted by an after construct is an already passed time instant, the effective baseline of the reaction is rounded off to the actual time of the call.

Regards, Andrey On Oct 26, 2009, at 10:01, Ivan Tarasov wrote:

I'm trying to understand what constitutes an RTS and how a Timber program translated into C is actually executed. So, I'm reading the RTS implementations' code.

In rtsARM/rts.c, in ASYNC implementation, lines 439-442 we can see the following code: if (LESS(m->baseline, now)) { m->baseline = now; // debug("^"); } Same code is present in ASYNC implementation in rtsPOSIX/rts.c, lines 354-355

That means that if the absolute time value for the baseline for the action to be scheduled is in the past, we set the baseline to the current time. However, since all the time calculations are relative to the baseline, that would mean that all the following actions to be scheduled from the one being scheduled at the moment would "drift". Is this an intended behavior? I'm not sure that's the right decision.

Ivan _______________________________________________ Timber mailing list Timber@haskell.org http://www.haskell.org/mailman/listinfo/timber

------------------------------------------------------------------------ Andrey Kruglyak PhD student http://www.andreykruglyak.com Dept. of Computer Science and Electrical Engineering Lulea University of Technology, Lulea, Sweden T +46 920 49 23 57 (office) T +46 706 16 76 03 (mobile) Office A2314 (A-huset) _______________________________________________ Timber mailing list Timber@haskell.org http://www.haskell.org/mailman/listinfo/timber

_______________________________________________ Timber mailing list Timber@haskell.org http://www.haskell.org/mailman/listinfo/timber

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 :

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