Subject: RE: TR: Q23/17
From: VINCENT Daniel FTRD/DTL/LAN (daniel.vincent#rd.francetelecom.com)
Date: Tue Nov 13 2001 - 17:30:47 GMT
>
> If the action is to be triggered at a "specific point in
> time", the action
> has to be entered. An action can only be entered from another
> action or from
> a state.
>
In the context, you must understand "action" as "transition"
> If the process is in a state, the SDL semantics (Z.100 11.2)
> requires that
> the Continuous signal is re-interpreted every time that NOW
> changes (that is
> - according to the semantics - continuously). How is it
> possible that the
> correct value of NOW can be missed? Why would the action be
> entered "too
> late"? How could it be entered any sooner?
A lot of possibilities : (do not forget that we are in a timed model, and
that
some tasks or outputs can take some time).
First, just the process is executing a 3 T.U. delaying task, and you have a
deadline in 2 T.U
how do you do that ?
You say, the design is not good ! but it is not so evident : the task can be
a loop
and you don't know how much time will be needed to execute the loop.
Secondly, do not forget that a PROVIDED has a lower priority than a common
INPUT.
So, if the queue of the process is not empty, the PROVIDED has little
chance.
>
>> >
> > You mention the problem of distributed system, and this is exactly
> > why we can not use the general NOW for controlling time
> everywhere in the
> > system : for that we rather use clocks defined locally.
>
> As far as I know there are many networks that have
> synchronised clocks,
HUM ? What about IP networks ?
> though I would agree that having a global clock of infinitely fine
> granularity is impossible. In reality each process must have its own
> relativistic clock.
>
>> > Concerning your example :
> >> TIMER T;
> >> DCL next_time Time := 0;
> >> SYNONYM period Time = EXTERNAL; /*the period*/
> >> ...
> >> next_time := next_time + period;
> >> SET ( next_time, T);
> > period should be of type Duration,
> (DanIel is - of course - correct)
> > but the biggest problem is that with an actual SDL timer (this means
> > with the actual semantics of timer and queues), you only
> specify a minimum
> > time interval between two SET, and not an exact one, which
> is intended with
> > cyclic timers.
>
> No. This is not true.
>
> In the above code, if period has the value 3, then by
> interpreting the two
> statements above after each timer expiry, T is set to the
> values: 3, 6, 9,
> 12 ..., regardless of the time between the actual timeout
> occurring and the
> next interpretation of SET.
What happens if you have in-between a task taking from 2 to 7 t.u. ?
>
> > How to achieve this is a problem that we have to deal with. With the
> > actual semantics, it is completely impossible. We will
> probably have to
> > propose some slight changes (to the semantics, even in
> Z100). Q6/10 will
> > accept or not.
>
> (Correction Q.13/17 - we have to get used to these new numbers)
OK, I just not remembered the good number. So I used the old one which is
still
present in everybody's mind.
>
> Why is this required? The user has the choice to set a timer
> relative to
> either NOW, or to the last value of the timer using the
> current semantics.
>
?? What is this ? last value of the timer ? expiry time ? reset time ?
probably I missed something in SDL'2000 ?
Nevertheless, slight changes concern not only timer setting and timer base
(NOW, local clocks ...)
but also handling of the time-out (normal signal, urgent(?), interruptive
(?) ...)
For example in TTCN, timeouts go to a special list affected to each process,
and this
list is different from the message queue. Some ral time systems may need
such a feature or even more;
> > (actually people can use something like SYNONYM MSEC Duration =
> > 0.001, SEC Duration = 1; but it is not convenient to write
> : PROVIDED (NOW
> >> = (T0 + (K * MSEC)));
>
> From a syntactic point of view the brackets are not necessary
> - this could
> be written
> NOW >= T0 +K*MSEC
> and in SDL-2000 the dotty notation (with appropriate operations)
> NOW >= T0+K.MSEC
>
I will not give my life for time units in SDL. It is on the table and I have
no strong feelings about it.
Nevertheless, consider that a guard on time is often more complicated than
the example I gave.
PS : As a former Lisp fan, I am not affraid by brackets, but rather by .MSEC
> --
> 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