[Timber] bug (?) in ASYNC implementation

[Andrey Kruglyak]

Ivan,

Actually, this has been a point of contention for some time. I will  
not pretend to know ALL the arguments for the current solution (I hope  
Johan Nordlander can answer you), but here are some ideas:

The "after"-construction is most commonly used (in the applications  
we've seen so far) to schedule actions past the current deadline. This  
case is not affected by this rule, and we do avoid any drift there.

When an action is posted with "after" and the new baseline has already  
passed, then since the deadline for the posted action is always  
defined relative to its baseline, not adjusting the baseline to the  
current time would allow for a situation when not only the baseline,  
but also the deadline of the reaction has passed. It would make it  
impossible to verify that such as system meets its deadlines.

Hope that makes some sense.

Regards,
Andrey

On Oct 26, 2009, at 10:17, Ivan Tarasov wrote:

> 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:
>> 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.)
> 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 <kruglyak at mac.com>:
>> 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

------------------------------------------------------------------------
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)