Hello Uwe,

I am glad to see that someone else stumbled on this problem. In fact
I studied it already earlier this year and got into a fight with the tool
vendor. If you read carefully the standard you will notice that there is in
fact a contradiction. Some very preoccupied people seem to be scared by the
fact that a repeat could lead to a blocking situation. If such a blocking
occurs, this would be a straight ahead programming error for which only the
programmer could be blamed and thus not the TTCN-3 standard.

The repeat in default behaviors is essential for handling test
events that are not fully predictable from a sequential point of view. For
example, the typical are-you-alive checks that servers would send in mobile
communication to verify that a mobile phone is still connected. This kind of
keep alive check is the perfect case for a default behavior where a repeat
needs to be present otherwise this default behavior will execute only once.

Some vendor sent me a very convoluted work around solution. I think
that reversing the standard with a CR is urgently needed.

Cheers
Bernard Stepien
University of Ottawa

---

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 Uwe Truetsch
Sent: 4 novembre 2010 10:29
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: using repeat within an altstep which is used itself as activated
default within an interleave statement

Hello,
there might be a dilemma within the ttcn-3 specification regarding usage
of repeat within interleave statement.
It is clearly specified that repeat must not be used inside an
interleave block.
It is also clearly specified that activated defaults function within
interleave.
This means that an repeat in an activated default could cause an error
when executed from an interleave rather than a normal alt.
Here is an example that shows the situation.

The question is should this situation cause an runtime error or not? If
not, then perhaps clarification should be made in the specification.

module repeatInDefaultFromInterleave {
type component M {
timer t1 := 1.0
timer t2 := 2.0
timer t3 := 0.1
}

altstep as() runs on M {
[] t3.timeout {
t3.start
repeat
}
}

testcase tc() runs on M {
t1.start
t2.start
t3.start

activate(as())

interleave {
[] t1.timeout {
log("t1 done")
}
[] t2.timeout {
log("t2 done")
}
}
}

control {
execute(tc())
}
}


BR.
Uwe

>
> Hello,

Hi Uwe,

I would assume that such a scenario should/would cause a compilation error.
Of course, it would require some more 'work' on the compiler's part though.
:-) A compilation error should also occur for any of the restrictions
described in ES 873-201-1 section 20.4 Restrictions a)

A runtime error would also be acceptable. What verdict should be assigned?
'error' would be my suggestion.

The earlier an error is caught the better, so I would prefer a compilation
error being flagged over a runtime error.

As Bernard pointed out, using a default without a repeat would cause it
To only execute once, which is the behaviour expected in an interleave, that
is, each alternative is executed

> there might be a dilemma within the ttcn-3 specification regarding usage
> of repeat within interleave statement.

> It is clearly specified that repeat must not be used inside an
> interleave block.

See ES 873-201-1 section 20.4 Restrictions a)

> It is also clearly specified that activated defaults function within
> interleave.

See ES 873-201-1 section 20.4 Semantic Description b) under the assumption
that the default was activated before entering the interleave.

> This means that an repeat in an activated default could cause an error
> when executed from an interleave rather than a normal alt.

What is/are the alternative(s)?

(a) Deactivate the defaults before entering the interleave (changes the
behaviour).

(b) Rewrite the default in such a way that it does not include a repeat if
possible.

(c) Rewrite the code without using the interleave? (it gets messy, but will
get the job done and won't suffer from the interleave restrictions.

Cheers,

Claude.

---

> Here is an example that shows the situation.
>
> The question is should this situation cause an runtime error or not? If
> not, then perhaps clarification should be made in the specification.
>
> module repeatInDefaultFromInterleave {
> type component M {
> timer t1 := 1.0
> timer t2 := 2.0
> timer t3 := 0.1
> }
>
> altstep as() runs on M {
> [] t3.timeout {
> t3.start
> repeat
> }
> }
>
> testcase tc() runs on M {
> t1.start
> t2.start
> t3.start
>
> activate(as())
>
> interleave {
> [] t1.timeout {
> log("t1 done")
> }
> [] t2.timeout {
> log("t2 done")
> }
> }
> }
>
> control {
> execute(tc())
> }
> }
>
>
> BR.
> Uwe

Hello Claude,
in your answers you say that the default inside an interleave will be
executed only once. Does this mean that although not all alternatives of
the interleave where satisfied yet interleave will be quit? As there is
nowhere mentioned that you can short-circuit an interleave via an
activated default I would expect the default being called over and over
again until the last alternative of the interleave statement is getting
satisfied.
What is your opinion about this?

Uwe

ext Claude Desroches wrote:
>> Hello,
>>
>
> Hi Uwe,
>
> I would assume that such a scenario should/would cause a compilation error.
> Of course, it would require some more 'work' on the compiler's part though.
> :-) A compilation error should also occur for any of the restrictions
> described in ES 873-201-1 section 20.4 Restrictions a)
>
> A runtime error would also be acceptable. What verdict should be assigned?
> 'error' would be my suggestion.
>
> The earlier an error is caught the better, so I would prefer a compilation
> error being flagged over a runtime error.
>
> As Bernard pointed out, using a default without a repeat would cause it
> To only execute once, which is the behaviour expected in an interleave, that
> is, each alternative is executed
>
>
>> there might be a dilemma within the ttcn-3 specification regarding usage
>> of repeat within interleave statement.
>>
>
>
>> It is clearly specified that repeat must not be used inside an
>> interleave block.
>>
>
> See ES 873-201-1 section 20.4 Restrictions a)
>
>
>> It is also clearly specified that activated defaults function within
>> interleave.
>>
>
> See ES 873-201-1 section 20.4 Semantic Description b) under the assumption
> that the default was activated before entering the interleave.
>
>
>> This means that an repeat in an activated default could cause an error
>> when executed from an interleave rather than a normal alt.
>>
>
> What is/are the alternative(s)?
>
> (a) Deactivate the defaults before entering the interleave (changes the
> behaviour).
>
> (b) Rewrite the default in such a way that it does not include a repeat if
> possible.
>
> (c) Rewrite the code without using the interleave? (it gets messy, but will
> get the job done and won't suffer from the interleave restrictions.
>
> Cheers,
>
> Claude.
>
>

---

>
>> Here is an example that shows the situation.
>>
>> The question is should this situation cause an runtime error or not? If
>> not, then perhaps clarification should be made in the specification.
>>
>> module repeatInDefaultFromInterleave {
>> type component M {
>> timer t1 := 1.0
>> timer t2 := 2.0
>> timer t3 := 0.1
>> }
>>
>> altstep as() runs on M {
>> [] t3.timeout {
>> t3.start
>> repeat
>> }
>> }
>>
>> testcase tc() runs on M {
>> t1.start
>> t2.start
>> t3.start
>>
>> activate(as())
>>
>> interleave {
>> [] t1.timeout {
>> log("t1 done")
>> }
>> [] t2.timeout {
>> log("t2 done")
>> }
>> }
>> }
>>
>> control {
>> execute(tc())
>> }
>> }
>>
>>
>> BR.
>> Uwe
>>

On 11/08/2010 09:30 AM, Uwe Truetsch wrote:
> Hello Claude,
> in your answers you say that the default inside an interleave will be
> executed only once. Does this mean that although not all alternatives
> of the interleave where satisfied yet interleave will be quit? As
> there is nowhere mentioned that you can short-circuit an interleave
> via an activated default I would expect the default being called over
> and over again until the last alternative of the interleave statement
> is getting satisfied.
> What is your opinion about this?
It is a direct consequence of the alt-expansion semantics. Since via the
expansion, the interleave becomes an alt-statement-tree, and at any
point only one of the nodes of the tree is the current alt-statement,
then if none of the alternatives in that alt statement match and an
activated default alternative is chosen instead, it leads to the
termination of that alt statement, i.e. the termination of the whole
tree (as only sub-trees of that tree could be chosen as next current alt
statement if one of the alternatives match).

A repeat then would of course only lead to the repetition of the
currently active alt statement and not of the whole interleave (i.e. all
the already messages matched by the interleave do not have to be matched
again).

BR, Jacob Wieland
>
> Uwe
>
> ext Claude Desroches wrote:
>>> Hello,
>>
>> Hi Uwe,
>>
>> I would assume that such a scenario should/would cause a compilation
>> error.
>> Of course, it would require some more 'work' on the compiler's part
>> though. :-) A compilation error should also occur for any of the
>> restrictions
>> described in ES 873-201-1 section 20.4 Restrictions a)
>>
>> A runtime error would also be acceptable. What verdict should be
>> assigned?
>> 'error' would be my suggestion.
>>
>> The earlier an error is caught the better, so I would prefer a
>> compilation
>> error being flagged over a runtime error.
>>
>> As Bernard pointed out, using a default without a repeat would cause it
>> To only execute once, which is the behaviour expected in an
>> interleave, that
>> is, each alternative is executed
>>> there might be a dilemma within the ttcn-3 specification regarding
>>> usage
>>> of repeat within interleave statement.
>>
>>> It is clearly specified that repeat must not be used inside an
>>> interleave block.
>>
>> See ES 873-201-1 section 20.4 Restrictions a)
>>
>>> It is also clearly specified that activated defaults function within
>>> interleave.
>>
>> See ES 873-201-1 section 20.4 Semantic Description b) under the
>> assumption that the default was activated before entering the
>> interleave.
>>> This means that an repeat in an activated default could cause an error
>>> when executed from an interleave rather than a normal alt.
>>
>> What is/are the alternative(s)?
>> (a) Deactivate the defaults before entering the interleave (changes
>> the behaviour).
>>
>> (b) Rewrite the default in such a way that it does not include a
>> repeat if
>> possible.
>>
>> (c) Rewrite the code without using the interleave? (it gets messy,
>> but will
>> get the job done and won't suffer from the interleave restrictions.
>>
>> Cheers,
>>
>> Claude.
>>
>>

---

>>
>>> Here is an example that shows the situation.
>>>
>>> The question is should this situation cause an runtime error or not? If
>>> not, then perhaps clarification should be made in the specification.
>>>
>>> module repeatInDefaultFromInterleave {
>>> type component M {
>>> timer t1 := 1.0
>>> timer t2 := 2.0
>>> timer t3 := 0.1
>>> }
>>>
>>> altstep as() runs on M {
>>> [] t3.timeout {
>>> t3.start
>>> repeat
>>> }
>>> }
>>>
>>> testcase tc() runs on M {
>>> t1.start
>>> t2.start
>>> t3.start
>>>
>>> activate(as())
>>>
>>> interleave {
>>> [] t1.timeout {
>>> log("t1 done")
>>> }
>>> [] t2.timeout {
>>> log("t2 done")
>>> }
>>> }
>>> }
>>>
>>> control {
>>> execute(tc())
>>> }
>>> }
>>>
>>>
>>> BR.
>>> Uwe

Hi Jacob,

Thanks for expanding on that. My thoughts are quite similar.

>
> On 11/08/2010 09:30 AM, Uwe Truetsch wrote:
> > Hello Claude,
> > in your answers you say that the default inside an interleave will be
> > executed only once. Does this mean that although not all alternatives
> > of the interleave where satisfied yet interleave will be quit? As
> > there is nowhere mentioned that you can short-circuit an interleave
> > via an activated default I would expect the default being called over
> > and over again until the last alternative of the interleave statement
> > is getting satisfied.
> > What is your opinion about this?

> It is a direct consequence of the alt-expansion semantics. Since via the
> expansion, the interleave becomes an alt-statement-tree, and at any
> point only one of the nodes of the tree is the current alt-statement,
> then if none of the alternatives in that alt statement match and an
> activated default alternative is chosen instead, it leads to the
> termination of that alt statement, i.e. the termination of the whole
> tree (as only sub-trees of that tree could be chosen as next current alt
> statement if one of the alternatives match).

The standard clearly stipulates that a match in a default (which does not
have a repeat) will cause the component to either terminate (using stop) or
continue execution by exiting the interleave (when no stop is present in the
alternative branch which was matched within the default).

Note: execution is transferred to the statement after the interleave
irrespective of whether none, some, or all alternatives have been matched.
Since this is not the expected behaviour, one might want to generate a
warning or even a runtime error to inform the user that an unexpected
behaviour has occurred.

>
> A repeat then would of course only lead to the repetition of the
> currently active alt statement and not of the whole interleave (i.e. all
> the already messages matched by the interleave do not have to be matched
> again).
>

Precisely.

I have more to say on this topic... stay tuned! :-)

Cheers,
Claude.

> BR, Jacob Wieland
> >
> > Uwe
> >
> > ext Claude Desroches wrote:
> >>> Hello,
> >>
> >> Hi Uwe,
> >>
> >> I would assume that such a scenario should/would cause a compilation
> >> error.
> >> Of course, it would require some more 'work' on the compiler's part
> >> though. :-) A compilation error should also occur for any of the
> >> restrictions
> >> described in ES 873-201-1 section 20.4 Restrictions a)
> >>
> >> A runtime error would also be acceptable. What verdict should be
> >> assigned?
> >> 'error' would be my suggestion.
> >>
> >> The earlier an error is caught the better, so I would prefer a
> >> compilation
> >> error being flagged over a runtime error.
> >>
> >> As Bernard pointed out, using a default without a repeat would cause it
> >> To only execute once, which is the behaviour expected in an
> >> interleave, that
> >> is, each alternative is executed
> >>> there might be a dilemma within the ttcn-3 specification regarding
> >>> usage
> >>> of repeat within interleave statement.
> >>
> >>> It is clearly specified that repeat must not be used inside an
> >>> interleave block.
> >>
> >> See ES 873-201-1 section 20.4 Restrictions a)
> >>
> >>> It is also clearly specified that activated defaults function within
> >>> interleave.
> >>
> >> See ES 873-201-1 section 20.4 Semantic Description b) under the
> >> assumption that the default was activated before entering the
> >> interleave.
> >>> This means that an repeat in an activated default could cause an error
> >>> when executed from an interleave rather than a normal alt.
> >>
> >> What is/are the alternative(s)?
> >> (a) Deactivate the defaults before entering the interleave (changes
> >> the behaviour).
> >>
> >> (b) Rewrite the default in such a way that it does not include a
> >> repeat if
> >> possible.
> >>
> >> (c) Rewrite the code without using the interleave? (it gets messy,
> >> but will
> >> get the job done and won't suffer from the interleave restrictions.
> >>
> >> Cheers,
> >>
> >> Claude.
> >>
> >>

---

> ---
> >>
> >>> Here is an example that shows the situation.
> >>>
> >>> The question is should this situation cause an runtime error or not?
> If
> >>> not, then perhaps clarification should be made in the specification.
> >>>
> >>> module repeatInDefaultFromInterleave {
> >>> type component M {
> >>> timer t1 := 1.0
> >>> timer t2 := 2.0
> >>> timer t3 := 0.1
> >>> }
> >>>
> >>> altstep as() runs on M {
> >>> [] t3.timeout {
> >>> t3.start
> >>> repeat
> >>> }
> >>> }
> >>>
> >>> testcase tc() runs on M {
> >>> t1.start
> >>> t2.start
> >>> t3.start
> >>>
> >>> activate(as())
> >>>
> >>> interleave {
> >>> [] t1.timeout {
> >>> log("t1 done")
> >>> }
> >>> [] t2.timeout {
> >>> log("t2 done")
> >>> }
> >>> }
> >>> }
> >>>
> >>> control {
> >>> execute(tc())
> >>> }
> >>> }
> >>>
> >>>
> >>> BR.
> >>> Uwe