Subject: Re: TR: Timer active expression
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Thu Apr 26 2001 - 18:19:19 GMT
Dear Suzanne (and colleagues),
Susanne Graf at Susanne.Graf#imag.fr wrote on 26/04/2001 13:14:
> Dear Rick,
>
> There are two questions. I will try to respond and will add a third one:
>
> 1. A (less interesting one) about who said what, but let's answer it too: I am
> not aware
> of the fact that we (the Interval project) said that there is a change in the
> semantics of
> the active predicate in SDL. The automaton representing a timer in the paper
> submitted to
> the SDL forum allows a timer to be active and expired.
Perhaps it was just my misunderstanding of the sentence in your own paper
about "Previous version of Z.100" ... This paper states that the current
version of Z.100 is different --- so I checked and could not find any
difference in the main body of Z.100.
> 2. A second question about what has changed and what has not changed about
> timers between
> SDL'96 and SDL 2000?
>
> a) the active predicate has not changed. On page 36 (of my version) of the ASM
> semantices
> the activity of a timer is very clearly defined by:
> Active(Pid,t) = (t.arrival > now) or (t in Pid.inport.queue)
> which is as in SDL'96
>
> b) what HAS changed is the expiration of a timer: a timer "expires" (meaning
> that a
> timeout signal is put into the queue of the owner process) "exactly" at
> expiration time";
> that means that the (implicit) timeout expiration has become an "eager"
> transition see our
> proposal), which we requested unnecessarily as a change in the above mentioned
> paper.
I cannot find that difference. The text in SDL-92 section 2.8 Semantics
seems to be identical to the text in SDL-200 section 11.15 Semantics (as far
as I can see).
However, I expect that you are correct so please can you tell me where can I
find this change in Z.100?
> 3. A third question arises about what should be the right definitions:
>
> a) should a timer become inactive as soon it has expired?
> to some extent it is a matter of taste, but it is dangerous to make such
> subtle changes
> (which would by the way complicate the reset operation, relying on the active
> predicate,
> when a timer has expired but the signal hasn't been consumed);
> We propose to add a (very useful) function "time-to-expiration" which subsumes
> the "has
> expired predicate" you are prosing, as it can be used to know if the timer has
> already
> expired or not: time-to-expiration<=0 and active meaning that the
> timeout-signal is still
> in the queue waiting to be consumed.
> Under some assumption the "time-to-expiry" function can be coded in today SDL,
> by
> remebering "now"" "right after setting the timer" (supposing however that
> these two
A better way is to store the time value for the set in a variable before
using SET, then using this variable as the first parameter of the SET.
> actions can be made "atomic"), but it is much cleaner to have a well-defined
> abstract data
> type timer with abstract operations set, reset, active, time-to-expiration. In
> this
> context "active and expired" can be defined as a derived, rather than as a
> primitive
> predicate.
I came to the same conclusion.
>
> b) should the timeout expiration be eager?
> definitively yes. If one wants to be able to assume some flexibility in the
> expiration of
> a timer, it is better to allow "flexible timeouts" where one can make
> assumption about an
> interval in which the timer will expire. Moreover, even with an eager
> expiration, there is
> still a lot of flexibility, as there is by default no constraint on the time
> that passes
> between expiration and consumption; the control of this time using the
> attributes eager,
> delayable or lazy is the purpose of our flexible definition of time progress.
Yes I understood that - the proposal I was making was to provide 3(a) as a
language defined feature.
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 1455 55 96 55 Fax:+44 1455 55 96 58 Mob.:+44 7970 50 96 50
This archive was generated by hypermail 2a23 : Mon May 05 2008 - 20:30:55 GMT