Hi all,

In "24.1 The Start timer operation" it is said "Starting a timer with the timer value 0.0 means that the timer times out immediately.". Does it mean that when the timer is created, it is mandatory to call triTimeout inside triStartTime?.



Thanks in advance

Sergio Lobato

Hello,

I would not expect an implementation to behave like this. Instead I
would expect that the timer implementation in the TRI PA implements this
requirement.

Best regards,

Sergio Lobato López schrieb:
> Hi all,
>
> In “24.1 The Start timer operation” it is said /“Starting a timer with
> the timer value 0.0 means that the timer times out immediately.”/. Does
> it mean that when the timer is created, it is mandatory to call
> triTimeout inside triStartTime?.
>
>
>
> Thanks in advance
>
> Sergio Lobato
>
>
>
>
>

--

---

Theofanis Vassiliou-Gioles email: vassiliou -at- testingtech.de
Testing Technologies IST GmbH phone: +49 30 726 19 190
Rosenthaler Str. 13 fax : +49 30 726 19 1920
D-10119 Berlin, Germany web : www.testingtech.de

Hi,
Sorry, maybe I didn't explain correctly, I meant that in the case of a timer is started with a value zero, should it be handled like any timer or it must be declared as timeout when it is created. (Always whole functionality for timers is implemented in the PA, of course).

Thanks & Regards
Sergio

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Theofanis Vassiliou-Gioles
Enviado el: martes, 14 de noviembre de 2006 12:28
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Re: timers

Hello,

I would not expect an implementation to behave like this. Instead I
would expect that the timer implementation in the TRI PA implements this
requirement.

Best regards,

Sergio Lobato López schrieb:
> Hi all,
>
> In "24.1 The Start timer operation" it is said /"Starting a timer with
> the timer value 0.0 means that the timer times out immediately."/. Does
> it mean that when the timer is created, it is mandatory to call
> triTimeout inside triStartTime?.
>
>
>
> Thanks in advance
>
> Sergio Lobato
>
>
>
>
>

--

---

Theofanis Vassiliou-Gioles email: vassiliou -at- testingtech.de
Testing Technologies IST GmbH phone: +49 30 726 19 190
Rosenthaler Str. 13 fax : +49 30 726 19 1920
D-10119 Berlin, Germany web : www.testingtech.de

Hi Sergio,

let me see if I get it correct this time.

I would (from a TTCN-3 perspective) always expect to write something like

timer t := 5.0 ;
t.start(0.0) ;
t.timeout;
setverdict(pass);


The timeout would always occur. Now, this is what you would expect.

The alternative (from a standards perspective) would be to define that
t.start(0.0) would never timeout.

I think the decision to introduce immediate timeout was more or less an
arbitrary one, but I see could reason for the specified version.

Having said this, I would also assume that

t.start(0.0)
alt {
[] t.timeout { setverdict(pass); }
[else] { setverdict(fail) ;
}

is in principle non-deterministic. IMHO is "immediately" not precise
enough to make this pattern deterministic.

Does this answer your question?

Best regards,
Theo

Sergio Lobato López schrieb:
> Hi, Sorry, maybe I didn't explain correctly, I meant that in the case
> of a timer is started with a value zero, should it be handled like
> any timer or it must be declared as timeout when it is created.
> (Always whole functionality for timers is implemented in the PA, of
> course).
>
> Thanks & Regards Sergio
>
>

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version
> 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de
> Theofanis Vassiliou-Gioles Enviado el: martes, 14 de noviembre de
> 2006 12:28 Para: This email address is being protected from spambots. You need JavaScript enabled to view it. Asunto: Re: timers
>
> Hello,
>
> I would not expect an implementation to behave like this. Instead I
> would expect that the timer implementation in the TRI PA implements
> this requirement.
>
> Best regards,
>
> Sergio Lobato López schrieb:
>> Hi all,
>>
>> In "24.1 The Start timer operation" it is said /"Starting a timer
>> with the timer value 0.0 means that the timer times out
>> immediately."/. Does it mean that when the timer is created, it is
>> mandatory to call triTimeout inside triStartTime?.
>>
>>
>>
>> Thanks in advance
>>
>> Sergio Lobato
>>
>>
>>
>>
>>
>

Hi,

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
> Theofanis Vassiliou-Gioles
> Sent: 2006. november 14. 14:20
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: timers

[...]
> I think the decision to introduce immediate timeout was more
> or less an
> arbitrary one, but I see could reason for the specified version.
>
> Having said this, I would also assume that
>
> t.start(0.0)
> alt {
> [] t.timeout { setverdict(pass); }
> [else] { setverdict(fail) ;
> }
>
> is in principle non-deterministic. IMHO is "immediately" not precise
> enough to make this pattern deterministic.

I do not think so. I am not a native English speaker but "immediately" means "without any delay". Altough the TTCN-3 std. is indeed ambiguous at many places, but --at least for me-- it seems trivial: as soon as code execution passes the event "t.start(0.0)" in the above example, the timer *must* be in an expired state even before the alt statement's evaluation begins. It cannot be anything else in a sequential execution environment.

Since a timer is always local to a test component, which must behave as a single-CPU single-threaded "computer", therefore according to the dynamic semantics the above verdict shall be a deterministic "pass".

Hi Theofanis,

This case is probably as deterministic as implementation of timers (in TRI PA or internal) is. :)

By issuing triTimeout() immediately when you receive a triStartTimer() request for a special case of 0.0 duration (this special case could be checked in the TRI PA implementation), you could make the thing deterministic, provided that the triStartTimer() call is blocking and statement execution does not proceed before user-implemented triStartTimer() callback completes. In this way, before completion of t.start(0.0) statement you have a guarantee that you have timeout event already in the internal queue before approaching next statement like t.timeout. If triStartTimer() call is non-blocking, however, things are worse and indeed, you may not achieve deterministic behaviour in this case.

Alexey

Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
Having said this, I would also assume that

t.start(0.0)
alt {
[] t.timeout { setverdict(pass); }
[else] { setverdict(fail) ;
}

is in principle non-deterministic. IMHO is "immediately" not precise
enough to make this pattern deterministic.

Hi all,

I agree with Gabor saying that the result of
t.start(0.0)
alt {
[] t.timeout { setverdict(pass); }
[else] { setverdict(fail) ;
}
is always deterministic.

You shall not forget something. The semantics of TTCN-3 is defined in Parts 1 and 4 of the standard, and not in other parts. In another words, the core language and the operational semantics has precedence over parts 5 and 6! Simply saying tool vendors shall assure that their implementations fulfil the language requirements and NOT the opposite way. No conclusion regarding the language semantics can be drawn from TRI or TCI.

BR, Gyorgy Rethy



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Alexey Mednonogov
Sent: Tuesday, 2006 November 14. 02:50 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: timers


Hi Theofanis,

This case is probably as deterministic as implementation of timers (in TRI PA or internal) is. :)

By issuing triTimeout() immediately when you receive a triStartTimer() request for a special case of 0.0 duration (this special case could be checked in the TRI PA implementation), you could make the thing deterministic, provided that the triStartTimer() call is blocking and statement execution does not proceed before user-implemented triStartTimer() callback completes. In this way, before completion of t.start(0.0) statement you have a guarantee that you have timeout event already in the internal queue before approaching next statement like t.timeout. If triStartTimer() call is non-blocking, however, things are worse and indeed, you may not achieve deterministic behaviour in this case.

Alexey

Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:


Having said this, I would also assume that

t.start(0.0)
alt {
[] t.timeout { setverdict(pass); }
[else] { setverdict(fail) ;
}

is in principle non-deterministic. IMHO is "immediately" not precise
enough to make this pattern deterministic.

Dear Gyorgy,

you are totally right that the semantics are defined by the part 1 *and*
part 4.

My comment that the behavior is non-deterministic basically comes from
Part 4/9.48.2 p.121 "9.48 Start timer operation" [Flow graph segment]

As you can see there is no special handling of the case timer-value = 0.0.

So I would conclude from the definition, which is normative that a timer
with a value of 0.0. is not handled in a special way.
It "creates" the timer, and set its to RUNNING, not TIMEOUT. So the
operational semantics does not pay any particular attention to the term
"immediatly". It just processes to the next TTCN-3 statement.

Having understood this I am expecting that a

t.start(x);

will always lead to a triStartTimer() call for all values of x >= 0.0.

And from then on the notion of time is in the hands of the platform
adapter that implements time.

Any comments?

Theo

György Réthy (IJ/ETH) schrieb:
> Hi all,
>
> I agree with Gabor saying that the result of
> t.start(0.0)
> alt {
> [] t.timeout { setverdict(pass); }
> [else] { setverdict(fail) ;
> }
> is always deterministic.
>
> You shall not forget something. The semantics of TTCN-3 is defined in
> Parts 1 and 4 of the standard, and not in other parts. In another
> words, the core language and the operational semantics has precedence
> over parts 5 and 6! Simply saying tool vendors shall assure that their
> implementations fulfil the language requirements and NOT the opposite
> way. No conclusion regarding the language semantics can be drawn from
> TRI or TCI.
>
> BR, Gyorgy Rethy
>
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey Mednonogov
> *Sent:* Tuesday, 2006 November 14. 02:50 PM
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: timers
>
> Hi Theofanis,
>
> This case is probably as deterministic as implementation of timers
> (in TRI PA or internal) is. :)
>
> By issuing triTimeout() immediately when you receive a
> triStartTimer() request for a special case of 0.0 duration (this
> special case could be checked in the TRI PA implementation), you
> could make the thing deterministic, provided that the
> triStartTimer() call is blocking and statement execution does not
> proceed before user-implemented triStartTimer() callback completes.
> In this way, before completion of t.start(0.0) statement you have a
> guarantee that you have timeout event already in the internal queue
> before approaching next statement like t.timeout. If triStartTimer()
> call is non-blocking, however, things are worse and indeed, you may
> not achieve deterministic behaviour in this case.
>
> Alexey
>
> */Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>
> Having said this, I would also assume that
>
> t.start(0.0)
> alt {
> [] t.timeout { setverdict(pass); }
> [else] { setverdict(fail) ;
> }
>
> is in principle non-deterministic. IMHO is "immediately" not precise
> enough to make this pattern deterministic.
>
>
>
>

Dear all,

The Core part states clearly in clause 23.2 (v3.2.1):
"...Starting a timer with the timer value 0.0 means that the timer times out immediately. ..."

To reach this behaviour nothing has to be indicated in the Operational Semantics! The OS is NOT modelling tool implementations but is a model for TTCN-3 LANGUAGE behaviour. Thus the OS specifies what to do when starting a timer and what to do when processing a timeout operation but it does not describe how the timer name is put on the timed-out list of the component. Simply saying, it starts the timer with value 0.0 that naturally will "expire" the very moment and the timer name is added to the timed-out list behind the curtain (comparably as pushing on incoming message to the end of a port queque) at the moment of executing the start operation (the OS, as a principal model does not handle real-system execution times).

To reproduce this behaviour I would expect from a real test system NOT to call triStartTimer() if the timer value is 0.0 but write the timer name during executing the start timer operation to the timed-out list of the component.

BR, Gyorgy

>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
>Theofanis Vassiliou-Gioles
>Sent: Wednesday, 2006 November 15. 11:04 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: timers
>
>Dear Gyorgy,
>
>you are totally right that the semantics are defined by the
>part 1 *and* part 4.
>
>My comment that the behavior is non-deterministic basically
>comes from Part 4/9.48.2 p.121 "9.48 Start timer operation"
>[Flow graph segment]
>
>As you can see there is no special handling of the case
>timer-value = 0.0.
>
>So I would conclude from the definition, which is normative
>that a timer with a value of 0.0. is not handled in a special way.
>It "creates" the timer, and set its to RUNNING, not TIMEOUT.
>So the operational semantics does not pay any particular
>attention to the term "immediatly". It just processes to the
>next TTCN-3 statement.
>
>Having understood this I am expecting that a
>
>t.start(x);
>
>will always lead to a triStartTimer() call for all values of x >= 0.0.
>
>And from then on the notion of time is in the hands of the
>platform adapter that implements time.
>
>Any comments?
>
>Theo
>
>György Réthy (IJ/ETH) schrieb:
>> Hi all,
>>
>> I agree with Gabor saying that the result of
>> t.start(0.0)
>> alt {
>> [] t.timeout { setverdict(pass); }
>> [else] { setverdict(fail) ;
>> }
>> is always deterministic.
>>
>> You shall not forget something. The semantics of TTCN-3 is
>defined in
>> Parts 1 and 4 of the standard, and not in other parts. In another
>> words, the core language and the operational semantics has
>precedence
>> over parts 5 and 6! Simply saying tool vendors shall assure
>that their
>> implementations fulfil the language requirements and NOT the
>opposite
>> way. No conclusion regarding the language semantics can be
>drawn from
>> TRI or TCI.
>>
>> BR, Gyorgy Rethy
>>
>>
>>
>

---

>

---

>> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
>> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
>Mednonogov
>> *Sent:* Tuesday, 2006 November 14. 02:50 PM
>> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
>> *Subject:* Re: timers
>>
>> Hi Theofanis,
>>
>> This case is probably as deterministic as implementation
>of timers
>> (in TRI PA or internal) is. :)
>>
>> By issuing triTimeout() immediately when you receive a
>> triStartTimer() request for a special case of 0.0 duration (this
>> special case could be checked in the TRI PA implementation), you
>> could make the thing deterministic, provided that the
>> triStartTimer() call is blocking and statement execution does not
>> proceed before user-implemented triStartTimer() callback
>completes.
>> In this way, before completion of t.start(0.0) statement
>you have a
>> guarantee that you have timeout event already in the
>internal queue
>> before approaching next statement like t.timeout. If
>triStartTimer()
>> call is non-blocking, however, things are worse and
>indeed, you may
>> not achieve deterministic behaviour in this case.
>>
>> Alexey
>>
>> */Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>>
>> Having said this, I would also assume that
>>
>> t.start(0.0)
>> alt {
>> [] t.timeout { setverdict(pass); }
>> [else] { setverdict(fail) ;
>> }
>>
>> is in principle non-deterministic. IMHO is
>"immediately" not precise
>> enough to make this pattern deterministic.
>>
>>
>>
>>
>

Dear Gyorgy,

sorry I do not understand this. Under which conditions has the OS
something to indicate? From your saying I was assuming that part 4 is
normative. And normative means for me, that the quoted flow-graph
segment sets the timer to RUNNING and not to TIMEOUT. And afterwards the
NEXT TTCN-3 statement can be executed.

Furthermore does Figure F.5 (ok, admitted it is informative) states
"start/"timer starts with non-negative duration"". The next state is
again RUNNING.

Does nobody else sees this contradiction?

IF the intend is, that the timer.start and timeout should be atomic
WITHIN the starting of the timer. I would insist that this fact is
defined in the OS. All other statements indicate that there is no
different handling for starting timers with non-negative values.

BR, Theo


György Réthy (IJ/ETH) schrieb:
> Dear all,
>
> The Core part states clearly in clause 23.2 (v3.2.1): "...Starting a
> timer with the timer value 0.0 means that the timer times out
> immediately. ..."
>
> To reach this behaviour nothing has to be indicated in the
> Operational Semantics! The OS is NOT modelling tool implementations
> but is a model for TTCN-3 LANGUAGE behaviour. Thus the OS specifies
> what to do when starting a timer and what to do when processing a
> timeout operation but it does not describe how the timer name is put
> on the timed-out list of the component. Simply saying, it starts the
> timer with value 0.0 that naturally will "expire" the very moment and
> the timer name is added to the timed-out list behind the curtain
> (comparably as pushing on incoming message to the end of a port
> queque) at the moment of executing the start operation (the OS, as a
> principal model does not handle real-system execution times).
>
> To reproduce this behaviour I would expect from a real test system
> NOT to call triStartTimer() if the timer value is 0.0 but write the
> timer name during executing the start timer operation to the
> timed-out list of the component.
>
> BR, Gyorgy
>
>>

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn
>> version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On
>> Behalf Of Theofanis Vassiliou-Gioles Sent: Wednesday, 2006 November
>> 15. 11:04 AM To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: timers
>>
>> Dear Gyorgy,
>>
>> you are totally right that the semantics are defined by the part 1
>> *and* part 4.
>>
>> My comment that the behavior is non-deterministic basically comes
>> from Part 4/9.48.2 p.121 "9.48 Start timer operation" [Flow graph
>> segment]
>>
>> As you can see there is no special handling of the case timer-value
>> = 0.0.
>>
>> So I would conclude from the definition, which is normative that a
>> timer with a value of 0.0. is not handled in a special way. It
>> "creates" the timer, and set its to RUNNING, not TIMEOUT. So the
>> operational semantics does not pay any particular attention to the
>> term "immediatly". It just processes to the next TTCN-3 statement.
>>
>> Having understood this I am expecting that a
>>
>> t.start(x);
>>
>> will always lead to a triStartTimer() call for all values of x >=
>> 0.0.
>>
>> And from then on the notion of time is in the hands of the platform
>> adapter that implements time.
>>
>> Any comments?
>>
>> Theo
>>
>> György Réthy (IJ/ETH) schrieb:
>>> Hi all,
>>>
>>> I agree with Gabor saying that the result of t.start(0.0) alt {
>>> [] t.timeout { setverdict(pass); } [else] { setverdict(fail) ; }
>>> is always deterministic.
>>>
>>> You shall not forget something. The semantics of TTCN-3 is
>> defined in
>>> Parts 1 and 4 of the standard, and not in other parts. In another
>>> words, the core language and the operational semantics has
>> precedence
>>> over parts 5 and 6! Simply saying tool vendors shall assure
>> that their
>>> implementations fulfil the language requirements and NOT the
>> opposite
>>> way. No conclusion regarding the language semantics can be
>> drawn from
>>> TRI or TCI.
>>>
>>> BR, Gyorgy Rethy
>>>
>>>
>>>
>>

---

>>

---

>>> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
>>> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
>> Mednonogov
>>> *Sent:* Tuesday, 2006 November 14. 02:50 PM *To:*
>>> This email address is being protected from spambots. You need JavaScript enabled to view it. *Subject:* Re: timers
>>>
>>> Hi Theofanis,
>>>
>>> This case is probably as deterministic as implementation
>> of timers
>>> (in TRI PA or internal) is. :)
>>>
>>> By issuing triTimeout() immediately when you receive a
>>> triStartTimer() request for a special case of 0.0 duration (this
>>> special case could be checked in the TRI PA implementation), you
>>> could make the thing deterministic, provided that the
>>> triStartTimer() call is blocking and statement execution does not
>>> proceed before user-implemented triStartTimer() callback
>> completes.
>>> In this way, before completion of t.start(0.0) statement
>> you have a
>>> guarantee that you have timeout event already in the
>> internal queue
>>> before approaching next statement like t.timeout. If
>> triStartTimer()
>>> call is non-blocking, however, things are worse and
>> indeed, you may
>>> not achieve deterministic behaviour in this case.
>>>
>>> Alexey
>>>
>>> */Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>>>
>>> Having said this, I would also assume that
>>>
>>> t.start(0.0) alt { [] t.timeout { setverdict(pass); } [else] {
>>> setverdict(fail) ; }
>>>
>>> is in principle non-deterministic. IMHO is
>> "immediately" not precise
>>> enough to make this pattern deterministic.
>>>
>>>
>>>
>>>
>

Dear TTCN-3 users,

I agree Gyorgy's interpretation of the standard.

In my opinion statement "immediately" is clear enough
compared to some other aspects of TTCN-3 standard. At least for me
"immediately" means that something is done before anything
else.

I think when a normal user reads "immediately" he/she would
also expect that things happen deterministically and not care
to read any fine print to find that there is a surprise.

I remember this issue was studied after the very first
TTCN-3 course I have ever held a couple of years ago in
Kokkola, Finland. Some student experimented by setting
timer to zero and this was then looked together.
And it was found that the timer expires the same
moment when T.start; statement has ended and the
timeout event can be found from the list of expired
timers.

Best regards,
Vesa-Matti

György Réthy (IJ/ETH) wrote:
> Dear all,
>
> The Core part states clearly in clause 23.2 (v3.2.1):
> "...Starting a timer with the timer value 0.0 means that the timer times out immediately. ..."
>
> To reach this behaviour nothing has to be indicated in the Operational Semantics! The OS is NOT modelling tool implementations but is a model for TTCN-3 LANGUAGE behaviour. Thus the OS specifies what to do when starting a timer and what to do when processing a timeout operation but it does not describe how the timer name is put on the timed-out list of the component. Simply saying, it starts the timer with value 0.0 that naturally will "expire" the very moment and the timer name is added to the timed-out list behind the curtain (comparably as pushing on incoming message to the end of a port queque) at the moment of executing the start operation (the OS, as a principal model does not handle real-system execution times).
>
> To reproduce this behaviour I would expect from a real test system NOT to call triStartTimer() if the timer value is 0.0 but write the timer name during executing the start timer operation to the timed-out list of the component.
>
> BR, Gyorgy
>
>>

---

Original Message

---

>> From: active_ttcn3 : mts stf133 ttcn version 3 - active
>> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
>> Theofanis Vassiliou-Gioles
>> Sent: Wednesday, 2006 November 15. 11:04 AM
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: timers
>>
>> Dear Gyorgy,
>>
>> you are totally right that the semantics are defined by the
>> part 1 *and* part 4.
>>
>> My comment that the behavior is non-deterministic basically
>> comes from Part 4/9.48.2 p.121 "9.48 Start timer operation"
>> [Flow graph segment]
>>
>> As you can see there is no special handling of the case
>> timer-value = 0.0.
>>
>> So I would conclude from the definition, which is normative
>> that a timer with a value of 0.0. is not handled in a special way.
>> It "creates" the timer, and set its to RUNNING, not TIMEOUT.
>> So the operational semantics does not pay any particular
>> attention to the term "immediatly". It just processes to the
>> next TTCN-3 statement.
>>
>> Having understood this I am expecting that a
>>
>> t.start(x);
>>
>> will always lead to a triStartTimer() call for all values of x >= 0.0.
>>
>> And from then on the notion of time is in the hands of the
>> platform adapter that implements time.
>>
>> Any comments?
>>
>> Theo
>>
>> György Réthy (IJ/ETH) schrieb:
>>> Hi all,
>>>
>>> I agree with Gabor saying that the result of
>>> t.start(0.0)
>>> alt {
>>> [] t.timeout { setverdict(pass); }
>>> [else] { setverdict(fail) ;
>>> }
>>> is always deterministic.
>>>
>>> You shall not forget something. The semantics of TTCN-3 is
>> defined in
>>> Parts 1 and 4 of the standard, and not in other parts. In another
>>> words, the core language and the operational semantics has
>> precedence
>>> over parts 5 and 6! Simply saying tool vendors shall assure
>> that their
>>> implementations fulfil the language requirements and NOT the
>> opposite
>>> way. No conclusion regarding the language semantics can be
>> drawn from
>>> TRI or TCI.
>>>
>>> BR, Gyorgy Rethy
>>>
>>>
>>>
>>

---

>>

---

>>> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
>>> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
>> Mednonogov
>>> *Sent:* Tuesday, 2006 November 14. 02:50 PM
>>> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
>>> *Subject:* Re: timers
>>>
>>> Hi Theofanis,
>>>
>>> This case is probably as deterministic as implementation
>> of timers
>>> (in TRI PA or internal) is. :)
>>>
>>> By issuing triTimeout() immediately when you receive a
>>> triStartTimer() request for a special case of 0.0 duration (this
>>> special case could be checked in the TRI PA implementation), you
>>> could make the thing deterministic, provided that the
>>> triStartTimer() call is blocking and statement execution does not
>>> proceed before user-implemented triStartTimer() callback
>> completes.
>>> In this way, before completion of t.start(0.0) statement
>> you have a
>>> guarantee that you have timeout event already in the
>> internal queue
>>> before approaching next statement like t.timeout. If
>> triStartTimer()
>>> call is non-blocking, however, things are worse and
>> indeed, you may
>>> not achieve deterministic behaviour in this case.
>>>
>>> Alexey
>>>
>>> */Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>>>
>>> Having said this, I would also assume that
>>>
>>> t.start(0.0)
>>> alt {
>>> [] t.timeout { setverdict(pass); }
>>> [else] { setverdict(fail) ;
>>> }
>>>
>>> is in principle non-deterministic. IMHO is
>> "immediately" not precise
>>> enough to make this pattern deterministic.
>>>
>>>
>>>
>>>
>

Dear Theo et. al.,

What setting the timer status to RUNNING in the OS means from the tool implementation point of view? It does not mean at all that if a timer state is changed to RUNNING in the OS, any tool should automatically call triStartTimer(). Quite the opposite: the OS is not meant to restrict ways tools are implemented to grant the semantics specified for the language.

Just a question: if the timer value is 0.0 but any positive float; can you see in the OS when and how the timer expires and its name is added to the timed-out list? The OS specifies execution of the start and timeout operations but not desribes what is happening between them; more preciselly it specifies that this is out of the scope of the OS:
"8.6.1.2 Phase II: Update
The update phase is related to all actions that are outside the scope of the operational semantics but influence the interpretation of a TTCN-3 module. The update phase comprises the following actions:
a) Time progress: All running timers are updated, i.e. the TIME-LEFT values of running timers are (possibly) decreased, and if due to the update a timer expires, the corresponding timer bindings are updated, i.e. TIME LEFT is set to 0.0 and STATUS is set to TIMEOUT;
...
"
Shortly, if you cannot see someone changing the state of a timer from RUNNING to TIMEOUT, it is quite a normal thing. But this still may happen at the very moment the start operation is executed (in the OS).

By the way, for more clarity it would not make any harm to make this behaviour explicit in the OS. But this does not mean, that the current version is incorrect or contradicts to part-1.

">... All other statements indicate
>that there is no different handling for starting timers with
>non-negative values."

Yes, exactly this is that I was explaining. The *OS* need not handle timers started with 0.0 in a special way because, it does not models the implementation of a test tool but the behaviour of the language. Hence the OS does not consider the time needed for the execution of the different operations, but if someone wants to implement the specified behaviour, it has to take into consideration real system aspects too.

In a summary, there is not the sligthest ambiguity regarding the correct result of the example mentioned earlier:
> t.start(0.0)
> alt {
> [] t.timeout { setverdict(pass); }
> [else] { setverdict(fail) ;
> }

Any tool not setting the verdict to pass in all cases the code is executed is simply not comfirming with the standard (see clause 4.3 of part-1:"For an implementation claiming to conform to this version of the language, all features specified in the present document shall be implemented consistently with the requirements given in the present document and in ES 201 873-4 [3].").

BR, Gyorgy

>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
>Theofanis Vassiliou-Gioles
>Sent: Wednesday, 2006 November 15. 12:27 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: timers
>
>Dear Gyorgy,
>
>sorry I do not understand this. Under which conditions has the
>OS something to indicate? From your saying I was assuming that
>part 4 is normative. And normative means for me, that the
>quoted flow-graph segment sets the timer to RUNNING and not to
>TIMEOUT. And afterwards the NEXT TTCN-3 statement can be executed.
>
>Furthermore does Figure F.5 (ok, admitted it is informative)
>states "start/"timer starts with non-negative duration"". The
>next state is again RUNNING.
>
>Does nobody else sees this contradiction?
>
>IF the intend is, that the timer.start and timeout should be
>atomic WITHIN the starting of the timer. I would insist that
>this fact is defined in the OS. All other statements indicate
>that there is no different handling for starting timers with
>non-negative values.
>
>BR, Theo
>
>
>György Réthy (IJ/ETH) schrieb:
>> Dear all,
>>
>> The Core part states clearly in clause 23.2 (v3.2.1): "...Starting a
>> timer with the timer value 0.0 means that the timer times out
>> immediately. ..."
>>
>> To reach this behaviour nothing has to be indicated in the
>Operational
>> Semantics! The OS is NOT modelling tool implementations but is a
>> model for TTCN-3 LANGUAGE behaviour. Thus the OS specifies
>what to do
>> when starting a timer and what to do when processing a timeout
>> operation but it does not describe how the timer name is put on the
>> timed-out list of the component. Simply saying, it starts the timer
>> with value 0.0 that naturally will "expire" the very moment and the
>> timer name is added to the timed-out list behind the curtain
>> (comparably as pushing on incoming message to the end of a port
>> queque) at the moment of executing the start operation (the OS, as a
>> principal model does not handle real-system execution times).
>>
>> To reproduce this behaviour I would expect from a real test
>system NOT
>> to call triStartTimer() if the timer value is 0.0 but write
>the timer
>> name during executing the start timer operation to the
>timed-out list
>> of the component.
>>
>> BR, Gyorgy
>>
>>>

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn
>>> version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On
>>> Behalf Of Theofanis Vassiliou-Gioles Sent: Wednesday, 2006 November
>>> 15. 11:04 AM To: This email address is being protected from spambots. You need JavaScript enabled to view it. Subject: Re: timers
>>>
>>> Dear Gyorgy,
>>>
>>> you are totally right that the semantics are defined by the part 1
>>> *and* part 4.
>>>
>>> My comment that the behavior is non-deterministic basically comes
>>> from Part 4/9.48.2 p.121 "9.48 Start timer operation" [Flow graph
>>> segment]
>>>
>>> As you can see there is no special handling of the case
>timer-value =
>>> 0.0.
>>>
>>> So I would conclude from the definition, which is normative that a
>>> timer with a value of 0.0. is not handled in a special way. It
>>> "creates" the timer, and set its to RUNNING, not TIMEOUT. So the
>>> operational semantics does not pay any particular attention to the
>>> term "immediatly". It just processes to the next TTCN-3 statement.
>>>
>>> Having understood this I am expecting that a
>>>
>>> t.start(x);
>>>
>>> will always lead to a triStartTimer() call for all values of x >=
>>> 0.0.
>>>
>>> And from then on the notion of time is in the hands of the platform
>>> adapter that implements time.
>>>
>>> Any comments?
>>>
>>> Theo
>>>
>>> György Réthy (IJ/ETH) schrieb:
>>>> Hi all,
>>>>
>>>> I agree with Gabor saying that the result of t.start(0.0) alt { []
>>>> t.timeout { setverdict(pass); } [else] { setverdict(fail) ; } is
>>>> always deterministic.
>>>>
>>>> You shall not forget something. The semantics of TTCN-3 is
>>> defined in
>>>> Parts 1 and 4 of the standard, and not in other parts. In another
>>>> words, the core language and the operational semantics has
>>> precedence
>>>> over parts 5 and 6! Simply saying tool vendors shall assure
>>> that their
>>>> implementations fulfil the language requirements and NOT the
>>> opposite
>>>> way. No conclusion regarding the language semantics can be
>>> drawn from
>>>> TRI or TCI.
>>>>
>>>> BR, Gyorgy Rethy
>>>>
>>>>
>>>>
>>>

---

>>>

---

>>>> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
>>>> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
>>> Mednonogov
>>>> *Sent:* Tuesday, 2006 November 14. 02:50 PM *To:*
>>>> This email address is being protected from spambots. You need JavaScript enabled to view it. *Subject:* Re: timers
>>>>
>>>> Hi Theofanis,
>>>>
>>>> This case is probably as deterministic as implementation
>>> of timers
>>>> (in TRI PA or internal) is. :)
>>>>
>>>> By issuing triTimeout() immediately when you receive a
>>>> triStartTimer() request for a special case of 0.0 duration (this
>>>> special case could be checked in the TRI PA implementation), you
>>>> could make the thing deterministic, provided that the
>>>> triStartTimer() call is blocking and statement execution does not
>>>> proceed before user-implemented triStartTimer() callback
>>> completes.
>>>> In this way, before completion of t.start(0.0) statement
>>> you have a
>>>> guarantee that you have timeout event already in the
>>> internal queue
>>>> before approaching next statement like t.timeout. If
>>> triStartTimer()
>>>> call is non-blocking, however, things are worse and
>>> indeed, you may
>>>> not achieve deterministic behaviour in this case.
>>>>
>>>> Alexey
>>>>
>>>> */Theofanis Vassiliou-Gioles <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>>>>
>>>> Having said this, I would also assume that
>>>>
>>>> t.start(0.0) alt { [] t.timeout { setverdict(pass); } [else] {
>>>> setverdict(fail) ; }
>>>>
>>>> is in principle non-deterministic. IMHO is
>>> "immediately" not precise
>>>> enough to make this pattern deterministic.
>>>>
>>>>
>>>>
>>>>
>>
>

Dear Gyorgy, et al,

although I agree mostly with your argumentation on 0.0-start, this
discussion raises a valid point about the precedence of part 1 vs. part 4.

While there is a clear statement about precendence with respect to the
syntax (4.2 in part 1):

"The language is specified syntactically and semantically in terms of a
textual description in the body of the current document (clauses 5 to 28)
and in a formalized way in annex A. In each case, when the textual
description is not exhaustive, the formal description completes it. If the
textual and the formal specifications are contradictory, the latter shall
take precedence."

- there seems to be no statement for the precedence in semantic questions.

There is a statement in 4.3 of part 1: "The present document does not
specify levels of implementation for the language. However, for an
implementation claiming to conform to this version of the language, all
implemented features of this document shall be consistent with the
requirements given in the present document."

There is not link at all to part 4?! Even in part 4, there is no
(conformance) justification for the normative definitions given in part 4
(if I have not missed sth.).

So, a main question remains: what is the relation between part 1 and part 4?
It seems that for every semantics question one should consult part 1 only -
and not part 4 - although part 4 defines the operational semantics for
TTCN-3 behaviors - including timers ?!

With best regards,

Ina.


>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of György
> Réthy (IJ/ETH)
> Sent: Wednesday, November 15, 2006 11:55 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: timers
> Importance: High
>
> Dear all,
>
> The Core part states clearly in clause 23.2 (v3.2.1):
> "...Starting a timer with the timer value 0.0 means that the
> timer times out immediately. ..."
>
> To reach this behaviour nothing has to be indicated in the
> Operational Semantics! The OS is NOT modelling tool
> implementations but is a model for TTCN-3 LANGUAGE behaviour.
> Thus the OS specifies what to do when starting a timer and
> what to do when processing a timeout operation but it does
> not describe how the timer name is put on the timed-out list
> of the component. Simply saying, it starts the timer with
> value 0.0 that naturally will "expire" the very moment and
> the timer name is added to the timed-out list behind the
> curtain (comparably as pushing on incoming message to the end
> of a port queque) at the moment of executing the start
> operation (the OS, as a principal model does not handle
> real-system execution times).
>
> To reproduce this behaviour I would expect from a real test
> system NOT to call triStartTimer() if the timer value is 0.0
> but write the timer name during executing the start timer
> operation to the timed-out list of the component.
>
> BR, Gyorgy
>
> >

---

Original Message

---

> >From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Theofanis Vassiliou-Gioles
> >Sent: Wednesday, 2006 November 15. 11:04 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: timers
> >
> >Dear Gyorgy,
> >
> >you are totally right that the semantics are defined by the part 1
> >*and* part 4.
> >
> >My comment that the behavior is non-deterministic basically
> comes from
> >Part 4/9.48.2 p.121 "9.48 Start timer operation"
> >[Flow graph segment]
> >
> >As you can see there is no special handling of the case
> timer-value =
> >0.0.
> >
> >So I would conclude from the definition, which is normative that a
> >timer with a value of 0.0. is not handled in a special way.
> >It "creates" the timer, and set its to RUNNING, not TIMEOUT.
> >So the operational semantics does not pay any particular
> attention to
> >the term "immediatly". It just processes to the next TTCN-3
> statement.
> >
> >Having understood this I am expecting that a
> >
> >t.start(x);
> >
> >will always lead to a triStartTimer() call for all values of
> x >= 0.0.
> >
> >And from then on the notion of time is in the hands of the platform
> >adapter that implements time.
> >
> >Any comments?
> >
> >Theo
> >
> >György Réthy (IJ/ETH) schrieb:
> >> Hi all,
> >>
> >> I agree with Gabor saying that the result of
> >> t.start(0.0)
> >> alt {
> >> [] t.timeout { setverdict(pass); }
> >> [else] { setverdict(fail) ;
> >> }
> >> is always deterministic.
> >>
> >> You shall not forget something. The semantics of TTCN-3 is
> >defined in
> >> Parts 1 and 4 of the standard, and not in other parts. In another
> >> words, the core language and the operational semantics has
> >precedence
> >> over parts 5 and 6! Simply saying tool vendors shall assure
> >that their
> >> implementations fulfil the language requirements and NOT the
> >opposite
> >> way. No conclusion regarding the language semantics can be
> >drawn from
> >> TRI or TCI.
> >>
> >> BR, Gyorgy Rethy
> >>
> >>
> >>
> >

---

> >

---

> >> *From:* active_ttcn3 : mts stf133 ttcn version 3 -
> active members
> >> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
> >Mednonogov
> >> *Sent:* Tuesday, 2006 November 14. 02:50 PM
> >> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> *Subject:* Re: timers
> >>
> >> Hi Theofanis,
> >>
> >> This case is probably as deterministic as implementation
> >of timers
> >> (in TRI PA or internal) is. :)
> >>
> >> By issuing triTimeout() immediately when you receive a
> >> triStartTimer() request for a special case of 0.0
> duration (this
> >> special case could be checked in the TRI PA
> implementation), you
> >> could make the thing deterministic, provided that the
> >> triStartTimer() call is blocking and statement
> execution does not
> >> proceed before user-implemented triStartTimer() callback
> >completes.
> >> In this way, before completion of t.start(0.0) statement
> >you have a
> >> guarantee that you have timeout event already in the
> >internal queue
> >> before approaching next statement like t.timeout. If
> >triStartTimer()
> >> call is non-blocking, however, things are worse and
> >indeed, you may
> >> not achieve deterministic behaviour in this case.
> >>
> >> Alexey
> >>
> >> */Theofanis Vassiliou-Gioles
> <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
> >>
> >> Having said this, I would also assume that
> >>
> >> t.start(0.0)
> >> alt {
> >> [] t.timeout { setverdict(pass); }
> >> [else] { setverdict(fail) ;
> >> }
> >>
> >> is in principle non-deterministic. IMHO is
> >"immediately" not precise
> >> enough to make this pattern deterministic.
> >>
> >>
> >>
> >>
> >
>

Dear Ina and others,

I agree with you that there should be an explicit precedence statement for the case if part-1 and part-4 contradicts.

I also agree that the precedence shall be given to part-1 for several reasons:
- most users will read only part-1 as the language specification, part-4 should not change anything "behind their backs".
- Part-4 itself gives the precedence to Part-1 in its Scope "The present document defines the operational semantics of TTCN-3. The present document is based on the TTCN-3 core language defined in ES 201 873-1 [1]." in an indirect way (again, I agree it should be explicit).

BR, Gyorgy

>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
>Schieferdecker, Ina
>Sent: Wednesday, 2006 November 15. 03:42 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: timers
>
>Dear Gyorgy, et al,
>
>although I agree mostly with your argumentation on 0.0-start,
>this discussion raises a valid point about the precedence of
>part 1 vs. part 4.
>
>While there is a clear statement about precendence with
>respect to the syntax (4.2 in part 1):
>
>"The language is specified syntactically and semantically in
>terms of a textual description in the body of the current
>document (clauses 5 to 28) and in a formalized way in annex A.
>In each case, when the textual description is not exhaustive,
>the formal description completes it. If the textual and the
>formal specifications are contradictory, the latter shall take
>precedence."
>
>- there seems to be no statement for the precedence in
>semantic questions.
>
>There is a statement in 4.3 of part 1: "The present document
>does not specify levels of implementation for the language.
>However, for an implementation claiming to conform to this
>version of the language, all implemented features of this
>document shall be consistent with the requirements given in
>the present document."
>
>There is not link at all to part 4?! Even in part 4, there is no
>(conformance) justification for the normative definitions
>given in part 4 (if I have not missed sth.).
>
>So, a main question remains: what is the relation between part
>1 and part 4?
>It seems that for every semantics question one should consult
>part 1 only - and not part 4 - although part 4 defines the
>operational semantics for
>TTCN-3 behaviors - including timers ?!
>
>With best regards,
>
>Ina.
>
>
>>

---

Original Message

---

>> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
>> [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of György Réthy (IJ/ETH)
>> Sent: Wednesday, November 15, 2006 11:55 AM
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: timers
>> Importance: High
>>
>> Dear all,
>>
>> The Core part states clearly in clause 23.2 (v3.2.1):
>> "...Starting a timer with the timer value 0.0 means that the timer
>> times out immediately. ..."
>>
>> To reach this behaviour nothing has to be indicated in the
>Operational
>> Semantics! The OS is NOT modelling tool implementations but is a
>> model for TTCN-3 LANGUAGE behaviour.
>> Thus the OS specifies what to do when starting a timer and
>what to do
>> when processing a timeout operation but it does not describe how the
>> timer name is put on the timed-out list of the component. Simply
>> saying, it starts the timer with value 0.0 that naturally will
>> "expire" the very moment and the timer name is added to the
>timed-out
>> list behind the curtain (comparably as pushing on incoming
>message to
>> the end of a port queque) at the moment of executing the start
>> operation (the OS, as a principal model does not handle real-system
>> execution times).
>>
>> To reproduce this behaviour I would expect from a real test
>system NOT
>> to call triStartTimer() if the timer value is 0.0 but write
>the timer
>> name during executing the start timer operation to the
>timed-out list
>> of the component.
>>
>> BR, Gyorgy
>>
>> >

---

Original Message

---

>> >From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only
>> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Theofanis Vassiliou-Gioles
>> >Sent: Wednesday, 2006 November 15. 11:04 AM
>> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> >Subject: Re: timers
>> >
>> >Dear Gyorgy,
>> >
>> >you are totally right that the semantics are defined by the part 1
>> >*and* part 4.
>> >
>> >My comment that the behavior is non-deterministic basically
>> comes from
>> >Part 4/9.48.2 p.121 "9.48 Start timer operation"
>> >[Flow graph segment]
>> >
>> >As you can see there is no special handling of the case
>> timer-value =
>> >0.0.
>> >
>> >So I would conclude from the definition, which is normative that a
>> >timer with a value of 0.0. is not handled in a special way.
>> >It "creates" the timer, and set its to RUNNING, not TIMEOUT.
>> >So the operational semantics does not pay any particular
>> attention to
>> >the term "immediatly". It just processes to the next TTCN-3
>> statement.
>> >
>> >Having understood this I am expecting that a
>> >
>> >t.start(x);
>> >
>> >will always lead to a triStartTimer() call for all values of
>> x >= 0.0.
>> >
>> >And from then on the notion of time is in the hands of the platform
>> >adapter that implements time.
>> >
>> >Any comments?
>> >
>> >Theo
>> >
>> >György Réthy (IJ/ETH) schrieb:
>> >> Hi all,
>> >>
>> >> I agree with Gabor saying that the result of
>> >> t.start(0.0)
>> >> alt {
>> >> [] t.timeout { setverdict(pass); }
>> >> [else] { setverdict(fail) ;
>> >> }
>> >> is always deterministic.
>> >>
>> >> You shall not forget something. The semantics of TTCN-3 is
>> >defined in
>> >> Parts 1 and 4 of the standard, and not in other parts. In another
>> >> words, the core language and the operational semantics has
>> >precedence
>> >> over parts 5 and 6! Simply saying tool vendors shall assure
>> >that their
>> >> implementations fulfil the language requirements and NOT the
>> >opposite
>> >> way. No conclusion regarding the language semantics can be
>> >drawn from
>> >> TRI or TCI.
>> >>
>> >> BR, Gyorgy Rethy
>> >>
>> >>
>> >>
>> >

---

>> >

---

>> >> *From:* active_ttcn3 : mts stf133 ttcn version 3 -
>> active members
>> >> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
>> >Mednonogov
>> >> *Sent:* Tuesday, 2006 November 14. 02:50 PM
>> >> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
>> >> *Subject:* Re: timers
>> >>
>> >> Hi Theofanis,
>> >>
>> >> This case is probably as deterministic as implementation
>> >of timers
>> >> (in TRI PA or internal) is. :)
>> >>
>> >> By issuing triTimeout() immediately when you receive a
>> >> triStartTimer() request for a special case of 0.0
>> duration (this
>> >> special case could be checked in the TRI PA
>> implementation), you
>> >> could make the thing deterministic, provided that the
>> >> triStartTimer() call is blocking and statement
>> execution does not
>> >> proceed before user-implemented triStartTimer() callback
>> >completes.
>> >> In this way, before completion of t.start(0.0) statement
>> >you have a
>> >> guarantee that you have timeout event already in the
>> >internal queue
>> >> before approaching next statement like t.timeout. If
>> >triStartTimer()
>> >> call is non-blocking, however, things are worse and
>> >indeed, you may
>> >> not achieve deterministic behaviour in this case.
>> >>
>> >> Alexey
>> >>
>> >> */Theofanis Vassiliou-Gioles
>> <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
>> >>
>> >> Having said this, I would also assume that
>> >>
>> >> t.start(0.0)
>> >> alt {
>> >> [] t.timeout { setverdict(pass); }
>> >> [else] { setverdict(fail) ;
>> >> }
>> >>
>> >> is in principle non-deterministic. IMHO is
>> >"immediately" not precise
>> >> enough to make this pattern deterministic.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>

Hi all,

It actually came to my mind that in the model below not only triStartTimer() call needs to be blocking (synchronous), but also triTimeout() call as well to ensure determinism of start 0.0 case, meaning that triTimeout() call returns only after timeout event has been actually inserted into internal test component queue. If it is asynchronous (triTimeout() call returns before), you still have no guarantee that the timeout event is there by the time of completing triStartTimer() call (even if the latter is blocking), and hence by the time of completing execution of TTCN-3 'start timer' statement as well.

Alexey
By issuing triTimeout() immediately when you receive a triStartTimer() request for a special case of 0.0 duration (this special case could be checked in the TRI PA implementation), you could make the thing deterministic, provided that the triStartTimer() call is blocking and statement execution does not proceed before user-implemented triStartTimer() callback completes. In this way, before completion of t.start(0.0) statement you have a guarantee that you have timeout event already in the internal queue before approaching next statement like t.timeout. If triStartTimer() call is non-blocking, however, things are worse and indeed, you may not achieve deterministic behaviour in this case.

Dear Gyorgy,

I only tried to understand the current status of the part 1/part 4 relation - I did not want to propose that part 1 should have precedence over part 4 - as I think it should exactly be the other way around - the same as the BNF has precedence. Otherwise, part 4 has no standing at all. Like the BNF, part 4 is for the vendors - less for the users - and should be binding. Meaning also that part 1 and part 4 should be consistent - inconcistencies should be resolved in either part. For example, the 0.0-start issue should be included in part 4.

Cheers, Ina.

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of György
> Réthy (IJ/ETH)
> Sent: Wednesday, November 15, 2006 5:00 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: timers
>
> Dear Ina and others,
>
> I agree with you that there should be an explicit precedence
> statement for the case if part-1 and part-4 contradicts.
>
> I also agree that the precedence shall be given to part-1 for
> several reasons:
> - most users will read only part-1 as the language
> specification, part-4 should not change anything "behind their backs".
> - Part-4 itself gives the precedence to Part-1 in its Scope
> "The present document defines the operational semantics of
> TTCN-3. The present document is based on the TTCN-3 core
> language defined in ES 201 873-1 [1]." in an indirect way
> (again, I agree it should be explicit).
>
> BR, Gyorgy
>
> >

---

Original Message

---

> >From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Schieferdecker, Ina
> >Sent: Wednesday, 2006 November 15. 03:42 PM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: timers
> >
> >Dear Gyorgy, et al,
> >
> >although I agree mostly with your argumentation on 0.0-start, this
> >discussion raises a valid point about the precedence of part
> 1 vs. part
> >4.
> >
> >While there is a clear statement about precendence with
> respect to the
> >syntax (4.2 in part 1):
> >
> >"The language is specified syntactically and semantically in
> terms of a
> >textual description in the body of the current document
> (clauses 5 to
> >28) and in a formalized way in annex A.
> >In each case, when the textual description is not exhaustive, the
> >formal description completes it. If the textual and the formal
> >specifications are contradictory, the latter shall take precedence."
> >
> >- there seems to be no statement for the precedence in semantic
> >questions.
> >
> >There is a statement in 4.3 of part 1: "The present document
> does not
> >specify levels of implementation for the language.
> >However, for an implementation claiming to conform to this
> version of
> >the language, all implemented features of this document shall be
> >consistent with the requirements given in the present document."
> >
> >There is not link at all to part 4?! Even in part 4, there is no
> >(conformance) justification for the normative definitions
> given in part
> >4 (if I have not missed sth.).
> >
> >So, a main question remains: what is the relation between part
> >1 and part 4?
> >It seems that for every semantics question one should consult part 1
> >only - and not part 4 - although part 4 defines the operational
> >semantics for
> >TTCN-3 behaviors - including timers ?!
> >
> >With best regards,
> >
> >Ina.
> >
> >
> >>

---

Original Message

---

> >> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only
> >> [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of György Réthy (IJ/ETH)
> >> Sent: Wednesday, November 15, 2006 11:55 AM
> >> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> Subject: Re: timers
> >> Importance: High
> >>
> >> Dear all,
> >>
> >> The Core part states clearly in clause 23.2 (v3.2.1):
> >> "...Starting a timer with the timer value 0.0 means that the timer
> >> times out immediately. ..."
> >>
> >> To reach this behaviour nothing has to be indicated in the
> >Operational
> >> Semantics! The OS is NOT modelling tool implementations but is a
> >> model for TTCN-3 LANGUAGE behaviour.
> >> Thus the OS specifies what to do when starting a timer and
> >what to do
> >> when processing a timeout operation but it does not
> describe how the
> >> timer name is put on the timed-out list of the component. Simply
> >> saying, it starts the timer with value 0.0 that naturally will
> >> "expire" the very moment and the timer name is added to the
> >timed-out
> >> list behind the curtain (comparably as pushing on incoming
> >message to
> >> the end of a port queque) at the moment of executing the start
> >> operation (the OS, as a principal model does not handle
> real-system
> >> execution times).
> >>
> >> To reproduce this behaviour I would expect from a real test
> >system NOT
> >> to call triStartTimer() if the timer value is 0.0 but write
> >the timer
> >> name during executing the start timer operation to the
> >timed-out list
> >> of the component.
> >>
> >> BR, Gyorgy
> >>
> >> >

---

Original Message

---

> >> >From: active_ttcn3 : mts stf133 ttcn version 3 - active
> >members only
> >> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Theofanis
> Vassiliou-Gioles
> >> >Sent: Wednesday, 2006 November 15. 11:04 AM
> >> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> >Subject: Re: timers
> >> >
> >> >Dear Gyorgy,
> >> >
> >> >you are totally right that the semantics are defined by the part 1
> >> >*and* part 4.
> >> >
> >> >My comment that the behavior is non-deterministic basically
> >> comes from
> >> >Part 4/9.48.2 p.121 "9.48 Start timer operation"
> >> >[Flow graph segment]
> >> >
> >> >As you can see there is no special handling of the case
> >> timer-value =
> >> >0.0.
> >> >
> >> >So I would conclude from the definition, which is
> normative that a
> >> >timer with a value of 0.0. is not handled in a special way.
> >> >It "creates" the timer, and set its to RUNNING, not TIMEOUT.
> >> >So the operational semantics does not pay any particular
> >> attention to
> >> >the term "immediatly". It just processes to the next TTCN-3
> >> statement.
> >> >
> >> >Having understood this I am expecting that a
> >> >
> >> >t.start(x);
> >> >
> >> >will always lead to a triStartTimer() call for all values of
> >> x >= 0.0.
> >> >
> >> >And from then on the notion of time is in the hands of
> the platform
> >> >adapter that implements time.
> >> >
> >> >Any comments?
> >> >
> >> >Theo
> >> >
> >> >György Réthy (IJ/ETH) schrieb:
> >> >> Hi all,
> >> >>
> >> >> I agree with Gabor saying that the result of
> >> >> t.start(0.0)
> >> >> alt {
> >> >> [] t.timeout { setverdict(pass); } [else] {
> setverdict(fail) ; }
> >> >> is always deterministic.
> >> >>
> >> >> You shall not forget something. The semantics of TTCN-3 is
> >> >defined in
> >> >> Parts 1 and 4 of the standard, and not in other parts.
> In another
> >> >> words, the core language and the operational semantics has
> >> >precedence
> >> >> over parts 5 and 6! Simply saying tool vendors shall assure
> >> >that their
> >> >> implementations fulfil the language requirements and NOT the
> >> >opposite
> >> >> way. No conclusion regarding the language semantics can be
> >> >drawn from
> >> >> TRI or TCI.
> >> >>
> >> >> BR, Gyorgy Rethy
> >> >>
> >> >>
> >> >>
> >> >

---

> >> >

---

> >> >> *From:* active_ttcn3 : mts stf133 ttcn version 3 -
> >> active members
> >> >> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Alexey
> >> >Mednonogov
> >> >> *Sent:* Tuesday, 2006 November 14. 02:50 PM
> >> >> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> >> *Subject:* Re: timers
> >> >>
> >> >> Hi Theofanis,
> >> >>
> >> >> This case is probably as deterministic as implementation
> >> >of timers
> >> >> (in TRI PA or internal) is. :)
> >> >>
> >> >> By issuing triTimeout() immediately when you receive a
> >> >> triStartTimer() request for a special case of 0.0
> >> duration (this
> >> >> special case could be checked in the TRI PA
> >> implementation), you
> >> >> could make the thing deterministic, provided that the
> >> >> triStartTimer() call is blocking and statement
> >> execution does not
> >> >> proceed before user-implemented triStartTimer() callback
> >> >completes.
> >> >> In this way, before completion of t.start(0.0) statement
> >> >you have a
> >> >> guarantee that you have timeout event already in the
> >> >internal queue
> >> >> before approaching next statement like t.timeout. If
> >> >triStartTimer()
> >> >> call is non-blocking, however, things are worse and
> >> >indeed, you may
> >> >> not achieve deterministic behaviour in this case.
> >> >>
> >> >> Alexey
> >> >>
> >> >> */Theofanis Vassiliou-Gioles
> >> <This email address is being protected from spambots. You need JavaScript enabled to view it.>/* wrote:
> >> >>
> >> >> Having said this, I would also assume that
> >> >>
> >> >> t.start(0.0)
> >> >> alt {
> >> >> [] t.timeout { setverdict(pass); }
> >> >> [else] { setverdict(fail) ;
> >> >> }
> >> >>
> >> >> is in principle non-deterministic. IMHO is
> >> >"immediately" not precise
> >> >> enough to make this pattern deterministic.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >
>

Hi Alexey,

From what I understood in this thread is:

a) an implementation has to guarantee the 0.0-behaviour
[Gyorgy Rethy wrote,
>> Any tool not setting the verdict to pass in all cases [...]]

b) the only way to achieve this is that NO triStartTimer will be called!
[Gyorgy Rethy wrote,
>> To reproduce this behaviour I would expect from a real test system
>> NOT to call triStartTimer() ]

Hence, no modification in TRI is required, with respect to
triEnqeueTimeout (to ensure the deterministic 0.0 behaviour), and also
not for triStartTimer to respect this special case of 0.0.(TRI says
"This operation is called by the TE when a timer needs to be started.")

BR, Theo


Alexey Mednonogov schrieb:
> Hi all,
> *//*
> It actually came to my mind that in the model below not only
> triStartTimer() call needs to be blocking (synchronous), but also
> triTimeout() call as well to ensure determinism of start 0.0 case,
> meaning that triTimeout() call returns only after timeout event has been
> actually inserted into internal test component queue. If it is
> asynchronous (triTimeout() call returns before), you still have no
> guarantee that the timeout event is there by the time of completing
> triStartTimer() call (even if the latter is blocking), and hence by the
> time of completing execution of TTCN-3 'start timer' statement as well.
>
> Alexey
>
> By issuing triTimeout() immediately when you receive a
> triStartTimer() request for a special case of 0.0 duration (this
> special case could be checked in the TRI PA implementation), you
> could make the thing deterministic, provided that the
> triStartTimer() call is blocking and statement execution does not
> proceed before user-implemented triStartTimer() callback completes.
> In this way, before completion of t.start(0.0) statement you have a
> guarantee that you have timeout event already in the internal queue
> before approaching next statement like t.timeout. If triStartTimer()
> call is non-blocking, however, things are worse and indeed, you may
> not achieve deterministic behaviour in this case.
>
>
>
>

Hi all,

I agree with Theo's summary.

BR, Gyorgy

>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
>Theofanis Vassiliou-Gioles
>Sent: Thursday, 2006 November 16. 10:41 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: timers
>
>Hi Alexey,
>
>From what I understood in this thread is:
>
>a) an implementation has to guarantee the 0.0-behaviour
>[Gyorgy Rethy wrote,
>>> Any tool not setting the verdict to pass in all cases [...]]
>
>b) the only way to achieve this is that NO triStartTimer will
>be called!
>[Gyorgy Rethy wrote,
>>> To reproduce this behaviour I would expect from a real test system
>>> NOT to call triStartTimer() ]
>
>Hence, no modification in TRI is required, with respect to
>triEnqeueTimeout (to ensure the deterministic 0.0 behaviour),
>and also not for triStartTimer to respect this special case of
>0.0.(TRI says "This operation is called by the TE when a timer
>needs to be started.")
>
>BR, Theo
>
>
>Alexey Mednonogov schrieb:
>> Hi all,
>> *//*
>> It actually came to my mind that in the model below not only
>> triStartTimer() call needs to be blocking (synchronous), but also
>> triTimeout() call as well to ensure determinism of start 0.0 case,
>> meaning that triTimeout() call returns only after timeout event has
>> been actually inserted into internal test component queue. If it is
>> asynchronous (triTimeout() call returns before), you still have no
>> guarantee that the timeout event is there by the time of completing
>> triStartTimer() call (even if the latter is blocking), and hence by
>> the time of completing execution of TTCN-3 'start timer'
>statement as well.
>>
>> Alexey
>>
>> By issuing triTimeout() immediately when you receive a
>> triStartTimer() request for a special case of 0.0 duration (this
>> special case could be checked in the TRI PA implementation), you
>> could make the thing deterministic, provided that the
>> triStartTimer() call is blocking and statement execution does not
>> proceed before user-implemented triStartTimer() callback
>completes.
>> In this way, before completion of t.start(0.0) statement
>you have a
>> guarantee that you have timeout event already in the
>internal queue
>> before approaching next statement like t.timeout. If
>triStartTimer()
>> call is non-blocking, however, things are worse and
>indeed, you may
>> not achieve deterministic behaviour in this case.
>>
>>
>>
>>
>

Hi,
Thank you very much; I think it's really clear.

Thanks,
Kind Regards
Sergio

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de György Réthy (IJ/ETH)
Enviado el: jueves, 16 de noviembre de 2006 12:39
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Re: timers

Hi all,

I agree with Theo's summary.

BR, Gyorgy

>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
>Theofanis Vassiliou-Gioles
>Sent: Thursday, 2006 November 16. 10:41 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: timers
>
>Hi Alexey,
>
>From what I understood in this thread is:
>
>a) an implementation has to guarantee the 0.0-behaviour
>[Gyorgy Rethy wrote,
>>> Any tool not setting the verdict to pass in all cases [...]]
>
>b) the only way to achieve this is that NO triStartTimer will
>be called!
>[Gyorgy Rethy wrote,
>>> To reproduce this behaviour I would expect from a real test system
>>> NOT to call triStartTimer() ]
>
>Hence, no modification in TRI is required, with respect to
>triEnqeueTimeout (to ensure the deterministic 0.0 behaviour),
>and also not for triStartTimer to respect this special case of
>0.0.(TRI says "This operation is called by the TE when a timer
>needs to be started.")
>
>BR, Theo
>
>
>Alexey Mednonogov schrieb:
>> Hi all,
>> *//*
>> It actually came to my mind that in the model below not only
>> triStartTimer() call needs to be blocking (synchronous), but also
>> triTimeout() call as well to ensure determinism of start 0.0 case,
>> meaning that triTimeout() call returns only after timeout event has
>> been actually inserted into internal test component queue. If it is
>> asynchronous (triTimeout() call returns before), you still have no
>> guarantee that the timeout event is there by the time of completing
>> triStartTimer() call (even if the latter is blocking), and hence by
>> the time of completing execution of TTCN-3 'start timer'
>statement as well.
>>
>> Alexey
>>
>> By issuing triTimeout() immediately when you receive a
>> triStartTimer() request for a special case of 0.0 duration (this
>> special case could be checked in the TRI PA implementation), you
>> could make the thing deterministic, provided that the
>> triStartTimer() call is blocking and statement execution does not
>> proceed before user-implemented triStartTimer() callback
>completes.
>> In this way, before completion of t.start(0.0) statement
>you have a
>> guarantee that you have timeout event already in the
>internal queue
>> before approaching next statement like t.timeout. If
>triStartTimer()
>> call is non-blocking, however, things are worse and
>indeed, you may
>> not achieve deterministic behaviour in this case.
>>
>>
>>
>>
>