TOPIC:

Hello,

I have a few questions concerning the new behavior of any timer/all
timer (as proposed for Standard Edition of the Core Language 3.4.1).

In the Chapter on declaring timers, there is a NOTE saying that local
timers have no further effect after the scope that introduced
them has been left.

Now, consider the following scenario:

altstep a(timer t) {
[] t.timeout { ... }
}

function f(float duration) {
timer t := duration;
activate(a(t));
t.start;
}

testcase T() runs on MyComponent {
f(3.0);
any port.receive;
}

Will this testcase wait forever because the local timer t cannot have
any effect anymore or is this negated by passing it
to the altstep? The former is suggested by the NOTE, the latter is
probably what every user who does not remember all
restrictions about everything, would expect.

In general, I think this NOTE is very unnecessary and I wonder about its
purpose.
I think it defies proper refactoring, because then extracting some part
of code which declares a local timer into a function (which is
a very normal procedure during programming to avoid duplication of code
or make code more readable in general) changes the
behavior of the statements in the same (original) scope following the
extracted statements (if they use any timer.timeout).

But, a syntactic refactoring should never result in a change of the
semantics of a program. Thus, implementation of such a refactoring
becomes very complicated (if done right), as it has to check additional
constraints (like the presence of local timers) to warn the user about.
Otherwise, you have a situation where you will find the error that you
introduced in your program only later at runtime (and not because of an
error, but because of a possible deadlock that you introduced). I don't
think this is the intended purpose of this note.

What the intended purpose is, I have no clue (other than clinging in
part to the semantics of any/all timer as defined in the former versions
of the standard).
If someone can clarify to me what the specific purpose of this confusing
language feature shoud be, I'd be very glad.

Thus, my proposal is this: Drop this note from the standard and let all
timers that have been started by a component (be they local or
component-declared) be the set of timers associated with the component.
Local timers can be removed from the timers pool once both their scope
has been left and they have timed out and that timeout has been noticed
(either by an explicit timeout like in the above
example or by an implicit any timer.timeout event).

Best regards,

Jacob Wieland

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

May 26-28, Tutorial "Theory & Practice of TTCN-3", Berlin (Germany)
www.testingtech.com/services/ttcn3_tutorial.php

June 3-6, TTCN-3 User Conference (T3UC), Madrid (Spain), Booth #T1
www.mtp.es/TTCN3UC2008/home.html

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Jacob,

Please find my answers to your questions below.

Best regards

Thomas

>

---

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 ext
>Jacob Wieland
>Sent: Monday, 19. May 2008 08:40
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Local timers
>
>Hello,
>
>I have a few questions concerning the new behavior of any
>timer/all timer (as proposed for Standard Edition of the Core
>Language 3.4.1).
>
>In the Chapter on declaring timers, there is a NOTE saying
>that local timers have no further effect after the scope that
>introduced them has been left.
>
>Now, consider the following scenario:
>
>altstep a(timer t) {
>[] t.timeout { ... }
>}
>
>function f(float duration) {
> timer t := duration;
> activate(a(t));
> t.start;
>}
>
>testcase T() runs on MyComponent {
> f(3.0);
> any port.receive;
>}
>
>Will this testcase wait forever because the local timer t
>cannot have any effect anymore or is this negated by passing
>it to the altstep? The former is suggested by the NOTE, the
>latter is probably what every user who does not remember all
>restrictions about everything, would expect.

TD: Yes, the test case will wait forever. The timer declared within the function f has no effect after f has been lefted. It ceases to exist. And although the altstep a(t) is still active, there will be no timer anymore for which a timeout could be caught.

>
>In general, I think this NOTE is very unnecessary and I wonder
>about its purpose.
>I think it defies proper refactoring, because then extracting
>some part of code which declares a local timer into a function
>(which is a very normal procedure during programming to avoid
>duplication of code or make code more readable in general)
>changes the behavior of the statements in the same (original)
>scope following the extracted statements (if they use any
>timer.timeout).

TD: Declaring a timer in a local function and then using this timer outside the scope of this function is not something that everybody would consider as 'proper' refactoring. At least I do not follow your argument here (but this is my personal opinion).

>
>But, a syntactic refactoring should never result in a change
>of the semantics of a program. Thus, implementation of such a
>refactoring becomes very complicated (if done right), as it
>has to check additional constraints (like the presence of
>local timers) to warn the user about.
>Otherwise, you have a situation where you will find the error
>that you introduced in your program only later at runtime (and
>not because of an error, but because of a possible deadlock
>that you introduced). I don't think this is the intended
>purpose of this note.
>
>What the intended purpose is, I have no clue (other than
>clinging in part to the semantics of any/all timer as defined
>in the former versions of the standard).

TD: Clinging to the semantics of the former versions means to have backwards compatibility. It has already been quite difficult to change the behaviour of any/all timer in a backwards incompatbible way (all timers on a component are considered now for any/all, independent of whether they are visible in the scope where any/all timer is evaluated). Changing the behaviour regarding the lifetime would cause similar discussions again because existing test suite that relied on the current semantics would have to be adapted. Also, I have to say, to me it makes sense limiting the lifetime of a timer to its declaring scope: Once the scope where an entity has been declared is left this entity cannot be accessed any more.

>If someone can clarify to me what the specific purpose of this
>confusing language feature shoud be, I'd be very glad.

TD: I hope that I succeeded at least in explaining. Even if we might have different opinions.

>
>Thus, my proposal is this: Drop this note from the standard
>and let all timers that have been started by a component (be
>they local or
>component-declared) be the set of timers associated with the component.
>Local timers can be removed from the timers pool once both
>their scope has been left and they have timed out and that
>timeout has been noticed (either by an explicit timeout like
>in the above example or by an implicit any timer.timeout event).

TD: Sorry, but I would not like to follow your proposal. I suggest to keep the draft for edition 3.4 as it is.

>
>Best regards,
>
>Jacob Wieland
>
>--
>

---

>

---

>Jacob Wieland
>Software Engineer
>
>Testing Technologies IST GmbH
>Michaelkirchstraße 17/18
>10179 Berlin, Germany
>
>Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
>Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>

---

>
>UPCOMING EVENTS!
>
>May 26-28, Tutorial "Theory & Practice of TTCN-3", Berlin
>(Germany) www.testingtech.com/services/ttcn3_tutorial.php
>
>June 3-6, TTCN-3 User Conference (T3UC), Madrid (Spain), Booth
>#T1 www.mtp.es/TTCN3UC2008/home.html
>
>

---

>

---

>Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
>Handelsregister HRB 77805, Amtsgericht Charlottenburg Ust ID
>Nr.: DE 813 143 070
>
>This e-mail may contain confidential and privileged material
>for the sole use of the intended recipient. Any review, use,
>distribution or disclosure by others is strictly prohibited.
>If you are not the intended recipient (or authorized to
>receive for the recipient), please contact the sender by reply
>e-mail and delete all copies of this message.
>

Hello Jacob,

From my point of view the note remarks that timers declared in functions are
local timers. Local timers are binded to the scope where they are declared,
so they die when leaving the scope where they were declared. I think is
clear to the user.

If you want to access a variable/timer inside an activated altstep (default)
you must declare the variable/timer in component scope to assure that the
variable/timer is always available during the testcase execution.


Best Regards,

Adrián Benéitez

---

Adrián Benéitez Turrión
SW Development Consultant
TEL: (+34) 91 353 15 64 (EXT. 128)
FAX: (+34) 91 359 61 79
E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.
Skype: adrian.beneitez

Metodos Y Tecnología (MTP)
Paseo de la Castellana 182, 10th Floor
28046 Madrid, Spain
WEB: www.mtp.es

---

---

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 Jacob Wieland
Enviado el: lunes, 19 de mayo de 2008 8:40
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Local timers

Hello,

I have a few questions concerning the new behavior of any timer/all
timer (as proposed for Standard Edition of the Core Language 3.4.1).

In the Chapter on declaring timers, there is a NOTE saying that local
timers have no further effect after the scope that introduced
them has been left.

Now, consider the following scenario:

altstep a(timer t) {
[] t.timeout { ... }
}

function f(float duration) {
timer t := duration;
activate(a(t));
t.start;
}

testcase T() runs on MyComponent {
f(3.0);
any port.receive;
}

Will this testcase wait forever because the local timer t cannot have
any effect anymore or is this negated by passing it
to the altstep? The former is suggested by the NOTE, the latter is
probably what every user who does not remember all
restrictions about everything, would expect.

In general, I think this NOTE is very unnecessary and I wonder about its
purpose.
I think it defies proper refactoring, because then extracting some part
of code which declares a local timer into a function (which is
a very normal procedure during programming to avoid duplication of code
or make code more readable in general) changes the
behavior of the statements in the same (original) scope following the
extracted statements (if they use any timer.timeout).

But, a syntactic refactoring should never result in a change of the
semantics of a program. Thus, implementation of such a refactoring
becomes very complicated (if done right), as it has to check additional
constraints (like the presence of local timers) to warn the user about.
Otherwise, you have a situation where you will find the error that you
introduced in your program only later at runtime (and not because of an
error, but because of a possible deadlock that you introduced). I don't
think this is the intended purpose of this note.

What the intended purpose is, I have no clue (other than clinging in
part to the semantics of any/all timer as defined in the former versions
of the standard).
If someone can clarify to me what the specific purpose of this confusing
language feature shoud be, I'd be very glad.

Thus, my proposal is this: Drop this note from the standard and let all
timers that have been started by a component (be they local or
component-declared) be the set of timers associated with the component.
Local timers can be removed from the timers pool once both their scope
has been left and they have timed out and that timeout has been noticed
(either by an explicit timeout like in the above
example or by an implicit any timer.timeout event).

Best regards,

Jacob Wieland

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

May 26-28, Tutorial "Theory & Practice of TTCN-3", Berlin (Germany)
www.testingtech.com/services/ttcn3_tutorial.php

June 3-6, TTCN-3 User Conference (T3UC), Madrid (Spain), Booth #T1
www.mtp.es/TTCN3UC2008/home.html

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

> >Will this testcase wait forever because the local timer t
> >cannot have any effect anymore or is this negated by passing
> >it to the altstep? The former is suggested by the NOTE, the
> >latter is probably what every user who does not remember all
> >restrictions about everything, would expect.
>
> TD: Yes, the test case will wait forever. The timer declared
> within the function f has no effect after f has been lefted.
> It ceases to exist. And although the altstep a(t) is still
> active, there will be no timer anymore for which a timeout
> could be caught.


What sounds simple on paper is hard to implement and causes
non-deterministic test execution easily, in particular if timeout
intervals become small.

Typically timers are implemented as "active timers", i.e. execution
threads that fire a timeout event after the time has elapsed. The
standard requires that the status of the timer (to be in scope or
ceased) is checked before firing the timeout event belonging to this
timer. The timer status however must be set by the TE, which runs an
independent execution thread. Only the TE knows whether a timer is in
scope or not. Thus, we have a classical race condition. Test results
become non-predictable.

According to our observations, this ND behavior occurs quite frequently
if timeout intervals are about < 10 msec with the technology currently
available. The probability drops for larger timeout values, but still
exists.

Declaring timers in component type definitions only does not completely
solve the ND; some timeouts could be still left over at the end of test
execution, similar to non-processed messages. But it would greatly
improve the current misery. A bad compromise (because it does not solve
the problem effectively) would be to prohibit to pass on timers to
different scopes (i.e. no timers as parameters in function calls), which
still requires changes in the standard though.

Since the ND is already there and probably remains, the current standard
version should at least say something about the resulting behavior if a
"spurious timeout" (as it is called in Tau Tester) occurs.

It is true that also refactoring of TTCN-3 code suffers from this ND.
But since the ND has been introduced at language level, no tool can
guarantee the same behavior of the refactored code.

Best regards,

Andreas

Hi Andreas,

it is difficult to figure out the relation of your comments to the local timer question. In part-5 there is no operation the PA could check the status of the timer before shooting a triTimeout. When receiving triStartTimer, the PA starts the timer and when it expires, it simply sends a triTimeout. The TE then decides if the scope is left already (to the direction of the higher scope!) or not, and depending on this it either writes the name of the timeout list of the component or ignores the triTimeout (e.g. may log a warning). So, I cannot see the race between the TE and the PA. The race is between the duration of the timer and the time function f() is left.

Regarding the race condition comment (for timers <10 ms), I have a feeling that you are measuring it on Windows and this limitation is coming from the platform you are using, not from the language or the TTCN-3 tool. On other platforms, the timer duration, below which the behaviour may become ND is certainly smaller by magnitude(s). If possible, more information would be interesting on this.

I do agree with Thomas, according to the defined semantics, the name of the timer "t" will not be on the timeout list when executing the any port.receive in T(), so it will wait until something is received on an MTC port (or stopped by a testcase guard timer or stopped manually etc.). But, as this semantics is _defined_, users shall be aware of it (and tools should remind them!).

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
> Ulrich, Andreas (CT)
> Sent: Monday, 19 May, 2008 11:35 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: AW: Local timers
>
> > >Will this testcase wait forever because the local timer t
> cannot have
> > >any effect anymore or is this negated by passing it to the
> altstep?
> > >The former is suggested by the NOTE, the latter is probably what
> > >every user who does not remember all restrictions about
> everything,
> > >would expect.
> >
> > TD: Yes, the test case will wait forever. The timer declared within
> > the function f has no effect after f has been lefted.
> > It ceases to exist. And although the altstep a(t) is still active,
> > there will be no timer anymore for which a timeout could be caught.
>
>
> What sounds simple on paper is hard to implement and causes
> non-deterministic test execution easily, in particular if
> timeout intervals become small.
>
> Typically timers are implemented as "active timers", i.e.
> execution threads that fire a timeout event after the time
> has elapsed. The standard requires that the status of the
> timer (to be in scope or
> ceased) is checked before firing the timeout event belonging
> to this timer. The timer status however must be set by the
> TE, which runs an independent execution thread. Only the TE
> knows whether a timer is in scope or not. Thus, we have a
> classical race condition. Test results become non-predictable.
>
> According to our observations, this ND behavior occurs quite
> frequently if timeout intervals are about < 10 msec with the
> technology currently available. The probability drops for
> larger timeout values, but still exists.
>
> Declaring timers in component type definitions only does not
> completely solve the ND; some timeouts could be still left
> over at the end of test execution, similar to non-processed
> messages. But it would greatly improve the current misery. A
> bad compromise (because it does not solve the problem
> effectively) would be to prohibit to pass on timers to
> different scopes (i.e. no timers as parameters in function
> calls), which still requires changes in the standard though.
>
> Since the ND is already there and probably remains, the
> current standard version should at least say something about
> the resulting behavior if a "spurious timeout" (as it is
> called in Tau Tester) occurs.
>
> It is true that also refactoring of TTCN-3 code suffers from this ND.
> But since the ND has been introduced at language level, no
> tool can guarantee the same behavior of the refactored code.
>
> Best regards,
>
> Andreas
>

Dear TTCN-3 users,

I would like to contribute to the comment made by Andreas concerning the
ND (non-deterministic) behaviour he observes in timer implementation with
the currently available technology.

OpenTTCN does not have any race condition related issues or ND behaviour
related to timer implementations. We would welcome you to verify this
claim independently.

This is true for OpenTTCN internal timer implementation, as well as
external timers implemented through standard TRI PA interface. OpenTTCN
SDK for C includes a portable example of external timer implementation
that was written very carefully, particularly to address issues related to
race conditions and determinism. We consider this example to be
thread-safe and providing deterministic timer behaviour.

Kind regards,
Alexey Mednonogov
OpenTTCN Oy

Andreas Ulrich wrote:

> According to our observations, this ND behavior occurs quite frequently
if timeout intervals are about < 10 msec with the technology currently
available. The probability drops for larger timeout values, but still
exists.

Hi György,

first of all, do we both agree that there is a race between a timeout and leaving the scope of a function? Reading your comments below I think yes. I don't mind whether the race is between TE and PA or between the duration of a timer and the time function as you put it.

What you describe is an approach to resolve the race by putting priority on the TE execution. It is one solution only, which is tool-dependent and may be also not the best one since it might cancel out certain fail/error cases.

The use of log warnings is not prescribed by the standard. Again, issuing a warning and ignoring the superfluous timeout is your specific solution to the race problem. Another one would be to issue a test case error, for example. I think that this is a kind of problem where standardization can contribute. My understanding of a standardized test method is that

* such kinds of problems that are known beforehand shall be avoided by a suitable language design;

* all remaining error cases are clearly described and a strategy is given to resolve them.

I think the current version of the standard can be still improved in this respect.

Best regards,

Andreas




> it is difficult to figure out the relation of your comments
> to the local timer question. In part-5 there is no operation
> the PA could check the status of the timer before shooting a
> triTimeout. When receiving triStartTimer, the PA starts the
> timer and when it expires, it simply sends a triTimeout. The
> TE then decides if the scope is left already (to the
> direction of the higher scope!) or not, and depending on this
> it either writes the name of the timeout list of the
> component or ignores the triTimeout (e.g. may log a warning).
> So, I cannot see the race between the TE and the PA. The race
> is between the duration of the timer and the time function
> f() is left.
>
> Regarding the race condition comment (for timers <10 ms), I
> have a feeling that you are measuring it on Windows and this
> limitation is coming from the platform you are using, not
> from the language or the TTCN-3 tool. On other platforms, the
> timer duration, below which the behaviour may become ND is
> certainly smaller by magnitude(s). If possible, more
> information would be interesting on this.
>
> I do agree with Thomas, according to the defined semantics,
> the name of the timer "t" will not be on the timeout list
> when executing the any port.receive in T(), so it will wait
> until something is received on an MTC port (or stopped by a
> testcase guard timer or stopped manually etc.). But, as this
> semantics is _defined_, users shall be aware of it (and tools
> should remind them!).
>
> 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
> > Ulrich, Andreas (CT)
> > Sent: Monday, 19 May, 2008 11:35 AM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: AW: Local timers
> >
> > > >Will this testcase wait forever because the local timer t
> > cannot have
> > > >any effect anymore or is this negated by passing it to the
> > altstep?
> > > >The former is suggested by the NOTE, the latter is probably what
> > > >every user who does not remember all restrictions about
> > everything,
> > > >would expect.
> > >
> > > TD: Yes, the test case will wait forever. The timer
> declared within
> > > the function f has no effect after f has been lefted.
> > > It ceases to exist. And although the altstep a(t) is
> still active,
> > > there will be no timer anymore for which a timeout could
> be caught.
> >
> >
> > What sounds simple on paper is hard to implement and causes
> > non-deterministic test execution easily, in particular if
> > timeout intervals become small.
> >
> > Typically timers are implemented as "active timers", i.e.
> > execution threads that fire a timeout event after the time
> > has elapsed. The standard requires that the status of the
> > timer (to be in scope or
> > ceased) is checked before firing the timeout event belonging
> > to this timer. The timer status however must be set by the
> > TE, which runs an independent execution thread. Only the TE
> > knows whether a timer is in scope or not. Thus, we have a
> > classical race condition. Test results become non-predictable.
> >
> > According to our observations, this ND behavior occurs quite
> > frequently if timeout intervals are about < 10 msec with the
> > technology currently available. The probability drops for
> > larger timeout values, but still exists.
> >
> > Declaring timers in component type definitions only does not
> > completely solve the ND; some timeouts could be still left
> > over at the end of test execution, similar to non-processed
> > messages. But it would greatly improve the current misery. A
> > bad compromise (because it does not solve the problem
> > effectively) would be to prohibit to pass on timers to
> > different scopes (i.e. no timers as parameters in function
> > calls), which still requires changes in the standard though.
> >
> > Since the ND is already there and probably remains, the
> > current standard version should at least say something about
> > the resulting behavior if a "spurious timeout" (as it is
> > called in Tau Tester) occurs.
> >
> > It is true that also refactoring of TTCN-3 code suffers
> from this ND.
> > But since the ND has been introduced at language level, no
> > tool can guarantee the same behavior of the refactored code.
> >
> > Best regards,
> >
> > Andreas
> >
>

Hello Andreas,

I am somehow lost in this email thread. What's your opinion on timeouts of local timers if there declaring scope has been left already. Should it still be possible to catch this timeout by 'any timer.timeout' or should have such a timeout no effect?

Best regards

Thomas

>

---

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 ext
>Ulrich, Andreas (CT)
>Sent: Monday, 19. May 2008 14:38
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Local timers
>
>Hi György,
>
>first of all, do we both agree that there is a race between a
>timeout and leaving the scope of a function? Reading your
>comments below I think yes. I don't mind whether the race is
>between TE and PA or between the duration of a timer and the
>time function as you put it.
>
>What you describe is an approach to resolve the race by
>putting priority on the TE execution. It is one solution only,
>which is tool-dependent and may be also not the best one since
>it might cancel out certain fail/error cases.
>
>The use of log warnings is not prescribed by the standard.
>Again, issuing a warning and ignoring the superfluous timeout
>is your specific solution to the race problem. Another one
>would be to issue a test case error, for example. I think that
>this is a kind of problem where standardization can
>contribute. My understanding of a standardized test method is that
>
>* such kinds of problems that are known beforehand shall be
>avoided by a suitable language design;
>
>* all remaining error cases are clearly described and a
>strategy is given to resolve them.
>
>I think the current version of the standard can be still
>improved in this respect.
>
>Best regards,
>
>Andreas
>
>
>
>
>> it is difficult to figure out the relation of your comments to the
>> local timer question. In part-5 there is no operation the PA could
>> check the status of the timer before shooting a triTimeout. When
>> receiving triStartTimer, the PA starts the timer and when it
>expires,
>> it simply sends a triTimeout. The TE then decides if the
>scope is left
>> already (to the direction of the higher scope!) or not, and
>depending
>> on this it either writes the name of the timeout list of the
>component
>> or ignores the triTimeout (e.g. may log a warning).
>> So, I cannot see the race between the TE and the PA. The race is
>> between the duration of the timer and the time function
>> f() is left.
>>
>> Regarding the race condition comment (for timers <10 ms), I have a
>> feeling that you are measuring it on Windows and this limitation is
>> coming from the platform you are using, not from the language or the
>> TTCN-3 tool. On other platforms, the timer duration, below which the
>> behaviour may become ND is certainly smaller by magnitude(s). If
>> possible, more information would be interesting on this.
>>
>> I do agree with Thomas, according to the defined semantics, the name
>> of the timer "t" will not be on the timeout list when executing the
>> any port.receive in T(), so it will wait until something is received
>> on an MTC port (or stopped by a testcase guard timer or stopped
>> manually etc.). But, as this semantics is _defined_, users shall be
>> aware of it (and tools should remind them!).
>>
>> 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 Ulrich, Andreas (CT)
>> > Sent: Monday, 19 May, 2008 11:35 AM
>> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > Subject: AW: Local timers
>> >
>> > > >Will this testcase wait forever because the local timer t
>> > cannot have
>> > > >any effect anymore or is this negated by passing it to the
>> > altstep?
>> > > >The former is suggested by the NOTE, the latter is
>probably what
>> > > >every user who does not remember all restrictions about
>> > everything,
>> > > >would expect.
>> > >
>> > > TD: Yes, the test case will wait forever. The timer
>> declared within
>> > > the function f has no effect after f has been lefted.
>> > > It ceases to exist. And although the altstep a(t) is
>> still active,
>> > > there will be no timer anymore for which a timeout could
>> be caught.
>> >
>> >
>> > What sounds simple on paper is hard to implement and causes
>> > non-deterministic test execution easily, in particular if timeout
>> > intervals become small.
>> >
>> > Typically timers are implemented as "active timers", i.e.
>> > execution threads that fire a timeout event after the time has
>> > elapsed. The standard requires that the status of the timer (to be
>> > in scope or
>> > ceased) is checked before firing the timeout event
>belonging to this
>> > timer. The timer status however must be set by the TE,
>which runs an
>> > independent execution thread. Only the TE knows whether a timer is
>> > in scope or not. Thus, we have a classical race condition. Test
>> > results become non-predictable.
>> >
>> > According to our observations, this ND behavior occurs quite
>> > frequently if timeout intervals are about < 10 msec with the
>> > technology currently available. The probability drops for larger
>> > timeout values, but still exists.
>> >
>> > Declaring timers in component type definitions only does not
>> > completely solve the ND; some timeouts could be still left over at
>> > the end of test execution, similar to non-processed
>messages. But it
>> > would greatly improve the current misery. A bad compromise
>(because
>> > it does not solve the problem
>> > effectively) would be to prohibit to pass on timers to different
>> > scopes (i.e. no timers as parameters in function calls),
>which still
>> > requires changes in the standard though.
>> >
>> > Since the ND is already there and probably remains, the current
>> > standard version should at least say something about the resulting
>> > behavior if a "spurious timeout" (as it is called in Tau Tester)
>> > occurs.
>> >
>> > It is true that also refactoring of TTCN-3 code suffers
>> from this ND.
>> > But since the ND has been introduced at language level, no
>tool can
>> > guarantee the same behavior of the refactored code.
>> >
>> > Best regards,
>> >
>> > Andreas
>> >
>>
>