TOPIC:

Hi!

I have encountered a somewhat obscure phrasing in the current
TTCN-3 core language standard concerning the 'check' statement,
from which it is not immediately appealing whether it has
blocking or non-blocking semantics. The phrasing is (clause
23.4.0):

"In this case [i.e. if matching criteria are not fullfilled and
check statement fails - AM] ... the next statement or alternative
to the check operation is evaluated."

So is it the next statement or is it the next alternative? :)

// Alternatives - example 1:

alt
{
[] MyPort1.check { MyNextStatement(); }
[] MyPort2.receive { Stmts(); }
}

// Standalone - example 2:

MyPort1.check; // S1
MyNextStatement(); // S2

From the clause above one may draw a conclusion that in the example 2
MyNextStatement() (S2) is evaluated after check statement fails, which
is I guess not the case. According to operational semantics 'check'
behaves much like 'receive', meaning that statement S1 above shall rather
be re-evaluated if check fails (in the absence of active defaults etc).

Proposed solution:

"In this case the copy of the top element of the queue is discarded
and test execution continues in the same manner as for any other
receiving operation, i.e. the next alternative to the check operation
is evaluated. If check is used as a standalone statement, it has
blocking semantics, i.e. it is considered to be a shorthand for an
alt statement with the only one alternative."

Best regards,
Alexey Mednonogov
OpenTTCN Oy

Hi Alexey,

I agree with your comment (the quoted text can be misinterpreted) and also with
the solution you are proposing. Could you pls. send a CR on this point to ETSI?

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 Alexey Mednonogov
> Sent: Wednesday, February 23, 2005 1:01 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Check statement - potential inconsistency
>
>
> Hi!
>
> I have encountered a somewhat obscure phrasing in the current
> TTCN-3 core language standard concerning the 'check' statement,
> from which it is not immediately appealing whether it has
> blocking or non-blocking semantics. The phrasing is (clause
> 23.4.0):
>
> "In this case [i.e. if matching criteria are not fullfilled and
> check statement fails - AM] ... the next statement or alternative
> to the check operation is evaluated."
>
> So is it the next statement or is it the next alternative? :)
>
> // Alternatives - example 1:
>
> alt
> {
> [] MyPort1.check { MyNextStatement(); }
> [] MyPort2.receive { Stmts(); }
> }
>
> // Standalone - example 2:
>
> MyPort1.check; // S1
> MyNextStatement(); // S2
>
> From the clause above one may draw a conclusion that in the example 2
> MyNextStatement() (S2) is evaluated after check statement fails, which
> is I guess not the case. According to operational semantics 'check'
> behaves much like 'receive', meaning that statement S1 above
> shall rather
> be re-evaluated if check fails (in the absence of active
> defaults etc).
>
> Proposed solution:
>
> "In this case the copy of the top element of the queue is discarded
> and test execution continues in the same manner as for any other
> receiving operation, i.e. the next alternative to the check operation
> is evaluated. If check is used as a standalone statement, it has
> blocking semantics, i.e. it is considered to be a shorthand for an
> alt statement with the only one alternative."
>
> Best regards,
> Alexey Mednonogov
> OpenTTCN Oy
>

Hello Alexey & Gyorgy

I've been wondering what the stand alone .checks are good for.

If one has a stand-alone .check, how does one know if it failed or not?
One might take a copy of the received values with a stand-alone .check
like in below (example from mockup)

MyPort.check(getcall(MyProc:{5, MyVar})
from MyPartner -> param (MyPar1Var, MyPar2Var));

Now, how do I know whether the values of MyPar1Var and MyPar2Var are
undefined or not after the statement?

Or what if I have the following stand-alone check statement in my module:

MyPort.check(receive(MyPdu:?));

If there is a pdu of type MyPdu in the port queue, the check matches
and execution continues. If there is there is not, and no defaults
have been actived, and if the standalone .check is interpreted as a
shorthand for the alt construct as it is said the op-semantics part of
standard, then isn't test component completely blocked in this case,
which causes dynamic error and the testcase to stop.

Br
Antti

>

---

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 György Réthy (IJ/ETH)
> Sent: Wednesday, February 23, 2005 16:15 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Check statement - potential inconsistency
>
>
> Hi Alexey,
>
> I agree with your comment (the quoted text can be misinterpreted)
> and also with the solution you are proposing. Could you pls. send a
> CR on this point to ETSI?
>
> 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 Alexey Mednonogov
> > Sent: Wednesday, February 23, 2005 1:01 PM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Check statement - potential inconsistency
> >
> >
> > Hi!
> >
> > I have encountered a somewhat obscure phrasing in the current
> > TTCN-3 core language standard concerning the 'check' statement,
> > from which it is not immediately appealing whether it has
> > blocking or non-blocking semantics. The phrasing is (clause
> > 23.4.0):
> >
> > "In this case [i.e. if matching criteria are not fullfilled and
> > check statement fails - AM] ... the next statement or alternative
> > to the check operation is evaluated."
> >
> > So is it the next statement or is it the next alternative? :)
> >
> > // Alternatives - example 1:
> >
> > alt
> > {
> > [] MyPort1.check { MyNextStatement(); }
> > [] MyPort2.receive { Stmts(); }
> > }
> >
> > // Standalone - example 2:
> >
> > MyPort1.check; // S1
> > MyNextStatement(); // S2
> >
> > From the clause above one may draw a conclusion that in the example 2
> > MyNextStatement() (S2) is evaluated after check statement fails, which
> > is I guess not the case. According to operational semantics 'check'
> > behaves much like 'receive', meaning that statement S1 above
> > shall rather
> > be re-evaluated if check fails (in the absence of active
> > defaults etc).
> >
> > Proposed solution:
> >
> > "In this case the copy of the top element of the queue is discarded
> > and test execution continues in the same manner as for any other
> > receiving operation, i.e. the next alternative to the check operation
> > is evaluated. If check is used as a standalone statement, it has
> > blocking semantics, i.e. it is considered to be a shorthand for an
> > alt statement with the only one alternative."
> >
> > Best regards,
> > Alexey Mednonogov
> > OpenTTCN Oy
> >
>

Hi Antti,

In my opinion, in the absence of activated defaults, check statement
from your example shall block until something is received, so
MyPar1Var, MyPar2Var shall be always defined after we proceed further
from check statement (if we proceed at all).

Now, for your other example, MyPort.check(receive(MyPdu:?)), if there
is nothing in the port queue at the time when this statement is reached
and evaluated for the first time, and no defaults are activated, then
this statement blocks until MyPdu is received and is put as the first
(top) element to the queue. A deadlock may happen only if there are no
other test components running, and then something like MyOtherPdu is
received and put to the front of the queue as the first element.

Regards,
Alexey

Antti Hyrkkanen wrote:

>Hello Alexey & Gyorgy
>
>I've been wondering what the stand alone .checks are good for.
>
>If one has a stand-alone .check, how does one know if it failed or not?
>One might take a copy of the received values with a stand-alone .check
>like in below (example from mockup)
>
> MyPort.check(getcall(MyProc:{5, MyVar})
> from MyPartner -> param (MyPar1Var, MyPar2Var));
>
>Now, how do I know whether the values of MyPar1Var and MyPar2Var are
>undefined or not after the statement?
>
>Or what if I have the following stand-alone check statement in my module:
>
> MyPort.check(receive(MyPdu:?));
>
>If there is a pdu of type MyPdu in the port queue, the check matches
>and execution continues. If there is there is not, and no defaults
>have been actived, and if the standalone .check is interpreted as a
>shorthand for the alt construct as it is said the op-semantics part of
>standard, then isn't test component completely blocked in this case,
>which causes dynamic error and the testcase to stop.
>
>Br
>Antti
>
>
>
>>

---

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 György Réthy (IJ/ETH)
>>Sent: Wednesday, February 23, 2005 16:15 PM
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: Check statement - potential inconsistency
>>
>>
>>Hi Alexey,
>>
>>I agree with your comment (the quoted text can be misinterpreted)
>>and also with the solution you are proposing. Could you pls. send a
>>CR on this point to ETSI?
>>
>>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 Alexey Mednonogov
>>>Sent: Wednesday, February 23, 2005 1:01 PM
>>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>>Subject: Check statement - potential inconsistency
>>>
>>>
>>>Hi!
>>>
>>>I have encountered a somewhat obscure phrasing in the current
>>>TTCN-3 core language standard concerning the 'check' statement,
>>>from which it is not immediately appealing whether it has
>>>blocking or non-blocking semantics. The phrasing is (clause
>>>23.4.0):
>>>
>>>"In this case [i.e. if matching criteria are not fullfilled and
>>>check statement fails - AM] ... the next statement or alternative
>>>to the check operation is evaluated."
>>>
>>>So is it the next statement or is it the next alternative? :)
>>>
>>>// Alternatives - example 1:
>>>
>>>alt
>>>{
>>> [] MyPort1.check { MyNextStatement(); }
>>> [] MyPort2.receive { Stmts(); }
>>>}
>>>
>>>// Standalone - example 2:
>>>
>>>MyPort1.check; // S1
>>>MyNextStatement(); // S2
>>>
>>> From the clause above one may draw a conclusion that in the example 2
>>>MyNextStatement() (S2) is evaluated after check statement fails, which
>>>is I guess not the case. According to operational semantics 'check'
>>>behaves much like 'receive', meaning that statement S1 above
>>>shall rather
>>>be re-evaluated if check fails (in the absence of active
>>>defaults etc).
>>>
>>>Proposed solution:
>>>
>>>"In this case the copy of the top element of the queue is discarded
>>>and test execution continues in the same manner as for any other
>>>receiving operation, i.e. the next alternative to the check operation
>>>is evaluated. If check is used as a standalone statement, it has
>>>blocking semantics, i.e. it is considered to be a shorthand for an
>>>alt statement with the only one alternative."
>>>
>>>Best regards,
>>>Alexey Mednonogov
>>>OpenTTCN Oy
>>>
>>>
>>>

Hi,

The whole example that you gave below is one single statement including the parameter storing part, therefore if the statement following this one is executed you know that MyPar1Var, MyPar2Var are bound.

Regarding your question on the use of a standalone .check, think about a single TTCN-2 receiving event with a qualifier (I mean there are no other events at the same intendation level). First the message content (value of the specified field/fields) has to be checked and if this check is successful AND the TTCN-2 constraint is matching too, the message is removed from the port. If the field check part fails, the message shall be left in the queue. This behaviour can not be "modelled" from TTCN-3 without a standalone .check.

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 Antti Hyrkkanen
> Sent: Wednesday, February 23, 2005 3:50 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Check statement - potential inconsistency
>
>
> Hello Alexey & Gyorgy
>
> I've been wondering what the stand alone .checks are good for.
>
> If one has a stand-alone .check, how does one know if it
> failed or not?
> One might take a copy of the received values with a stand-alone .check
> like in below (example from mockup)
>
> MyPort.check(getcall(MyProc:{5, MyVar})
> from MyPartner -> param (MyPar1Var, MyPar2Var));
>
> Now, how do I know whether the values of MyPar1Var and MyPar2Var are
> undefined or not after the statement?
>
> Or what if I have the following stand-alone check statement
> in my module:
>
> MyPort.check(receive(MyPdu:?));
>
> If there is a pdu of type MyPdu in the port queue, the check matches
> and execution continues. If there is there is not, and no defaults
> have been actived, and if the standalone .check is interpreted as a
> shorthand for the alt construct as it is said the op-semantics part of
> standard, then isn't test component completely blocked in this case,
> which causes dynamic error and the testcase to stop.
>
> Br
> Antti
>
> >

---

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 György Réthy (IJ/ETH)
> > Sent: Wednesday, February 23, 2005 16:15 PM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Check statement - potential inconsistency
> >
> >
> > Hi Alexey,
> >
> > I agree with your comment (the quoted text can be misinterpreted)
> > and also with the solution you are proposing. Could you pls. send a
> > CR on this point to ETSI?
> >
> > 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 Alexey Mednonogov
> > > Sent: Wednesday, February 23, 2005 1:01 PM
> > > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > Subject: Check statement - potential inconsistency
> > >
> > >
> > > Hi!
> > >
> > > I have encountered a somewhat obscure phrasing in the current
> > > TTCN-3 core language standard concerning the 'check' statement,
> > > from which it is not immediately appealing whether it has
> > > blocking or non-blocking semantics. The phrasing is (clause
> > > 23.4.0):
> > >
> > > "In this case [i.e. if matching criteria are not fullfilled and
> > > check statement fails - AM] ... the next statement or alternative
> > > to the check operation is evaluated."
> > >
> > > So is it the next statement or is it the next alternative? :)
> > >
> > > // Alternatives - example 1:
> > >
> > > alt
> > > {
> > > [] MyPort1.check { MyNextStatement(); }
> > > [] MyPort2.receive { Stmts(); }
> > > }
> > >
> > > // Standalone - example 2:
> > >
> > > MyPort1.check; // S1
> > > MyNextStatement(); // S2
> > >
> > > From the clause above one may draw a conclusion that in
> the example 2
> > > MyNextStatement() (S2) is evaluated after check statement
> fails, which
> > > is I guess not the case. According to operational
> semantics 'check'
> > > behaves much like 'receive', meaning that statement S1 above
> > > shall rather
> > > be re-evaluated if check fails (in the absence of active
> > > defaults etc).
> > >
> > > Proposed solution:
> > >
> > > "In this case the copy of the top element of the queue is
> discarded
> > > and test execution continues in the same manner as for any other
> > > receiving operation, i.e. the next alternative to the
> check operation
> > > is evaluated. If check is used as a standalone statement, it has
> > > blocking semantics, i.e. it is considered to be a shorthand for an
> > > alt statement with the only one alternative."
> > >
> > > Best regards,
> > > Alexey Mednonogov
> > > OpenTTCN Oy
> > >
> >
>

Hi Alexey

>

---

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 Alexey Mednonogov
> Sent: Wednesday, February 23, 2005 17:08 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Check statement - potential inconsistency
> Hi Antti,
>
> In my opinion, in the absence of activated defaults, check statement
> from your example shall block until something is received, so
> MyPar1Var, MyPar2Var shall be always defined after we proceed further
> from check statement (if we proceed at all)

Yes, this is how I think also, when the check statement is blocking.

However, I'm not sure if I understood correctly your proposed
solution:

>>>"In this case the copy of the top element of the queue is discarded
>>>and test execution continues in the same manner as for any other
>>>receiving operation, i.e. the next alternative to the check operation
>>>is evaluated. If check is used as a standalone statement, it has
>>>blocking semantics, i.e. it is considered to be a shorthand for an
>>>alt statement with the only one alternative."


If I have code like below

...
MyPort.check(receive(MyPdu:?));
MyPort.receive;
log("A comment);
...

is the equivalent longer form of that then

A)

alt
{
[] MyPort.check(receive(MyPdu:?))
{
MyPort.receive;
}
}
log("A comment);

or

B)
alt
{
[] MyPort.check(receive(MyPdu:?))
{
}
}
MyPort.receive;
log("A comment);


If it is A, then it looks like C-lang

if (something)
foo();
log("A comment);

in which the curly brackets have been omitted, which I personally
don't see as very good practice.


> Now, for your other example, MyPort.check(receive(MyPdu:?)), if there
> is nothing in the port queue at the time when this statement is reached
> and evaluated for the first time, and no defaults are activated, then
> this statement blocks until MyPdu is received and is put as the first
> (top) element to the queue. A deadlock may happen only if there are no
> other test components running, and then something like MyOtherPdu is
> received and put to the front of the queue as the first element.

In A and B, don't I have an instant deadlock if there is something
else in the port queue than what I am trying to match with (MyPdu:?).
Why I think there is deadlock is because:

the check fails with the copy of the value that is on the queue
the queue value remains in the queue
the check will fail from now on, even if a value of type MyPdu is
received, because the non-matching value is still as the first
value in the queue, and the matching is always done against it.

The standard says about the alt construct the following
(Mockup 20.1.1 Execution of alternative behaviour)

"The test case shall stop and indicate a dynamic error if a test
component is completely blocked. This means none of the alternatives
can be chosen, no relevant test component is running, no relevant
timer is running and all relevant ports contain at least one message,
call, reply or exception that do not match."

Did I miss something somewhere?

Br
Antti

> Regards,
> Alexey
>
> Antti Hyrkkanen wrote:
>
> >Hello Alexey & Gyorgy
> >
> >I've been wondering what the stand alone .checks are good for.
> >
> >If one has a stand-alone .check, how does one know if it failed or not?
> >One might take a copy of the received values with a stand-alone .check
> >like in below (example from mockup)
> >
> > MyPort.check(getcall(MyProc:{5, MyVar})
> > from MyPartner -> param (MyPar1Var, MyPar2Var));
> >
> >Now, how do I know whether the values of MyPar1Var and MyPar2Var are
> >undefined or not after the statement?
> >
> >Or what if I have the following stand-alone check statement in my module:
> >
> > MyPort.check(receive(MyPdu:?));
> >
> >If there is a pdu of type MyPdu in the port queue, the check matches
> >and execution continues. If there is there is not, and no defaults
> >have been actived, and if the standalone .check is interpreted as a
> >shorthand for the alt construct as it is said the op-semantics part of
> >standard, then isn't test component completely blocked in this case,
> >which causes dynamic error and the testcase to stop.
> >
> >Br
> >Antti
>
>
>
>>

---

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 György Réthy (IJ/ETH)
>>Sent: Wednesday, February 23, 2005 16:15 PM
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: Check statement - potential inconsistency
>>
>>
>>Hi Alexey,
>>
>>I agree with your comment (the quoted text can be misinterpreted)
>>and also with the solution you are proposing. Could you pls. send a
>>CR on this point to ETSI?
>>
>>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 Alexey Mednonogov
>>>Sent: Wednesday, February 23, 2005 1:01 PM
>>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>>Subject: Check statement - potential inconsistency
>>>
>>>
>>>Hi!
>>>
>>>I have encountered a somewhat obscure phrasing in the current
>>>TTCN-3 core language standard concerning the 'check' statement,
>>>from which it is not immediately appealing whether it has
>>>blocking or non-blocking semantics. The phrasing is (clause
>>>23.4.0):
>>>
>>>"In this case [i.e. if matching criteria are not fullfilled and
>>>check statement fails - AM] ... the next statement or alternative
>>>to the check operation is evaluated."
>>>
>>>So is it the next statement or is it the next alternative? :)
>>>
>>>// Alternatives - example 1:
>>>
>>>alt
>>>{
>>> [] MyPort1.check { MyNextStatement(); }
>>> [] MyPort2.receive { Stmts(); }
>>>}
>>>
>>>// Standalone - example 2:
>>>
>>>MyPort1.check; // S1
>>>MyNextStatement(); // S2
>>>
>>> From the clause above one may draw a conclusion that in the example 2
>>>MyNextStatement() (S2) is evaluated after check statement fails, which
>>>is I guess not the case. According to operational semantics 'check'
>>>behaves much like 'receive', meaning that statement S1 above
>>>shall rather
>>>be re-evaluated if check fails (in the absence of active
>>>defaults etc).
>>>
>>>Proposed solution:
>>>
>>>"In this case the copy of the top element of the queue is discarded
>>>and test execution continues in the same manner as for any other
>>>receiving operation, i.e. the next alternative to the check operation
>>>is evaluated. If check is used as a standalone statement, it has
>>>blocking semantics, i.e. it is considered to be a shorthand for an
>>>alt statement with the only one alternative."
>>>
>>>Best regards,
>>>Alexey Mednonogov
>>>OpenTTCN Oy

Hi all,

The correct resolution of the example
...
MyPort.check(receive(MyPdu:?));
MyPort.receive;
log("A comment);

is alternative C (basically your B but the standalone receive is resolved too):
alt {
[] MyPort.check(receive(MyPdu:?)) {}
}
alt {
[] MyPort.receive {}
}
log("A comment);

The two standalone statements are independent from each other and hence resolved
independently.

It is clear, that the check operation blocks the component IF
- the top element of the queue is not the type MyPdu and
- there is no activated default which could remove the top element or continue
execution on a timeout branch

And, as you correctly pointed out, if check blocks the component, this shall
lead to a dynamic test case error.

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.]
> Sent: Thursday, February 24, 2005 9:33 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Check statement - potential inconsistency
>
>
> Hi Alexey
>
> >

---

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 Alexey Mednonogov
> > Sent: Wednesday, February 23, 2005 17:08 PM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Check statement - potential inconsistency
> > Hi Antti,
> >
> > In my opinion, in the absence of activated defaults, check statement
> > from your example shall block until something is received, so
> > MyPar1Var, MyPar2Var shall be always defined after we
> proceed further
> > from check statement (if we proceed at all)
>
> Yes, this is how I think also, when the check statement is blocking.
>
> However, I'm not sure if I understood correctly your proposed
> solution:
>
> >>>"In this case the copy of the top element of the queue is discarded
> >>>and test execution continues in the same manner as for any other
> >>>receiving operation, i.e. the next alternative to the
> check operation
> >>>is evaluated. If check is used as a standalone statement, it has
> >>>blocking semantics, i.e. it is considered to be a shorthand for an
> >>>alt statement with the only one alternative."
>
>
> If I have code like below
>
> ...
> MyPort.check(receive(MyPdu:?));
> MyPort.receive;
> log("A comment);
> ...
>
> is the equivalent longer form of that then
>
> A)
>
> alt
> {
> [] MyPort.check(receive(MyPdu:?))
> {
> MyPort.receive;
> }
> }
> log("A comment);
>
> or
>
> B)
> alt
> {
> [] MyPort.check(receive(MyPdu:?))
> {
> }
> }
> MyPort.receive;
> log("A comment);
>
>
> If it is A, then it looks like C-lang
>
> if (something)
> foo();
> log("A comment);
>
> in which the curly brackets have been omitted, which I personally
> don't see as very good practice.
>
>
> > Now, for your other example,
> MyPort.check(receive(MyPdu:?)), if there
> > is nothing in the port queue at the time when this
> statement is reached
> > and evaluated for the first time, and no defaults are
> activated, then
> > this statement blocks until MyPdu is received and is put as
> the first
> > (top) element to the queue. A deadlock may happen only if
> there are no
> > other test components running, and then something like MyOtherPdu is
> > received and put to the front of the queue as the first element.
>
> In A and B, don't I have an instant deadlock if there is something
> else in the port queue than what I am trying to match with (MyPdu:?).
> Why I think there is deadlock is because:
>
> the check fails with the copy of the value that is on the queue
> the queue value remains in the queue
> the check will fail from now on, even if a value of type MyPdu is
> received, because the non-matching value is still as the first
> value in the queue, and the matching is always done against it.
>
> The standard says about the alt construct the following
> (Mockup 20.1.1 Execution of alternative behaviour)
>
> "The test case shall stop and indicate a dynamic error if a test
> component is completely blocked. This means none of the
> alternatives
> can be chosen, no relevant test component is running, no relevant
> timer is running and all relevant ports contain at least
> one message,
> call, reply or exception that do not match."
>
> Did I miss something somewhere?
>
> Br
> Antti
>
> > Regards,
> > Alexey
> >
> > Antti Hyrkkanen wrote:
> >
> > >Hello Alexey & Gyorgy
> > >
> > >I've been wondering what the stand alone .checks are good for.
> > >
> > >If one has a stand-alone .check, how does one know if it
> failed or not?
> > >One might take a copy of the received values with a
> stand-alone .check
> > >like in below (example from mockup)
> > >
> > > MyPort.check(getcall(MyProc:{5, MyVar})
> > > from MyPartner -> param (MyPar1Var, MyPar2Var));
> > >
> > >Now, how do I know whether the values of MyPar1Var and
> MyPar2Var are
> > >undefined or not after the statement?
> > >
> > >Or what if I have the following stand-alone check
> statement in my module:
> > >
> > > MyPort.check(receive(MyPdu:?));
> > >
> > >If there is a pdu of type MyPdu in the port queue, the
> check matches
> > >and execution continues. If there is there is not, and no defaults
> > >have been actived, and if the standalone .check is interpreted as a
> > >shorthand for the alt construct as it is said the
> op-semantics part of
> > >standard, then isn't test component completely blocked in
> this case,
> > >which causes dynamic error and the testcase to stop.
> > >
> > >Br
> > >Antti
> >
> >
> >
> >>

---

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 Gy?rgy R?thy (IJ/ETH)
> >>Sent: Wednesday, February 23, 2005 16:15 PM
> >>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >>Subject: Re: Check statement - potential inconsistency
> >>
> >>
> >>Hi Alexey,
> >>
> >>I agree with your comment (the quoted text can be misinterpreted)
> >>and also with the solution you are proposing. Could you pls. send a
> >>CR on this point to ETSI?
> >>
> >>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 Alexey Mednonogov
> >>>Sent: Wednesday, February 23, 2005 1:01 PM
> >>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >>>Subject: Check statement - potential inconsistency
> >>>
> >>>
> >>>Hi!
> >>>
> >>>I have encountered a somewhat obscure phrasing in the current
> >>>TTCN-3 core language standard concerning the 'check' statement,
> >>>from which it is not immediately appealing whether it has
> >>>blocking or non-blocking semantics. The phrasing is (clause
> >>>23.4.0):
> >>>
> >>>"In this case [i.e. if matching criteria are not fullfilled and
> >>>check statement fails - AM] ... the next statement or alternative
> >>>to the check operation is evaluated."
> >>>
> >>>So is it the next statement or is it the next alternative? :)
> >>>
> >>>// Alternatives - example 1:
> >>>
> >>>alt
> >>>{
> >>> [] MyPort1.check { MyNextStatement(); }
> >>> [] MyPort2.receive { Stmts(); }
> >>>}
> >>>
> >>>// Standalone - example 2:
> >>>
> >>>MyPort1.check; // S1
> >>>MyNextStatement(); // S2
> >>>
> >>> From the clause above one may draw a conclusion that in
> the example 2
> >>>MyNextStatement() (S2) is evaluated after check statement
> fails, which
> >>>is I guess not the case. According to operational semantics 'check'
> >>>behaves much like 'receive', meaning that statement S1 above
> >>>shall rather
> >>>be re-evaluated if check fails (in the absence of active
> >>>defaults etc).
> >>>
> >>>Proposed solution:
> >>>
> >>>"In this case the copy of the top element of the queue is discarded
> >>>and test execution continues in the same manner as for any other
> >>>receiving operation, i.e. the next alternative to the
> check operation
> >>>is evaluated. If check is used as a standalone statement, it has
> >>>blocking semantics, i.e. it is considered to be a shorthand for an
> >>>alt statement with the only one alternative."
> >>>
> >>>Best regards,
> >>>Alexey Mednonogov
> >>>OpenTTCN Oy
>

Hi Antti,

I agree with Gyorgy, and you are right, there is a deadlock
in the situation that you described. Good question is does
it lead to a deadlock of the whole test campaign in the
presence of other running components that can potentially
terminate the blocked one.

Alexey

Antti Hyrkkanen wrote:

>Hi Alexey
>
>
>
>>

---

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 Alexey Mednonogov
>>Sent: Wednesday, February 23, 2005 17:08 PM
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: Check statement - potential inconsistency
>>Hi Antti,
>>
>>In my opinion, in the absence of activated defaults, check statement
>>from your example shall block until something is received, so
>>MyPar1Var, MyPar2Var shall be always defined after we proceed further
>>from check statement (if we proceed at all)
>>
>>
>
>Yes, this is how I think also, when the check statement is blocking.
>
>However, I'm not sure if I understood correctly your proposed
>solution:
>
>
>
>>>>"In this case the copy of the top element of the queue is discarded
>>>>and test execution continues in the same manner as for any other
>>>>receiving operation, i.e. the next alternative to the check operation
>>>>is evaluated. If check is used as a standalone statement, it has
>>>>blocking semantics, i.e. it is considered to be a shorthand for an
>>>>alt statement with the only one alternative."
>>>>
>>>>
>
>
>If I have code like below
>
> ...
> MyPort.check(receive(MyPdu:?));
> MyPort.receive;
> log("A comment);
> ...
>
>is the equivalent longer form of that then
>
>A)
>
> alt
> {
> [] MyPort.check(receive(MyPdu:?))
> {
> MyPort.receive;
> }
> }
> log("A comment);
>
>or
>
>B)
> alt
> {
> [] MyPort.check(receive(MyPdu:?))
> {
> }
> }
> MyPort.receive;
> log("A comment);
>
>
>If it is A, then it looks like C-lang
>
> if (something)
> foo();
> log("A comment);
>
>in which the curly brackets have been omitted, which I personally
>don't see as very good practice.
>
>
>
>
>>Now, for your other example, MyPort.check(receive(MyPdu:?)), if there
>>is nothing in the port queue at the time when this statement is reached
>>and evaluated for the first time, and no defaults are activated, then
>>this statement blocks until MyPdu is received and is put as the first
>>(top) element to the queue. A deadlock may happen only if there are no
>>other test components running, and then something like MyOtherPdu is
>>received and put to the front of the queue as the first element.
>>
>>
>
>In A and B, don't I have an instant deadlock if there is something
>else in the port queue than what I am trying to match with (MyPdu:?).
>Why I think there is deadlock is because:
>
> the check fails with the copy of the value that is on the queue
> the queue value remains in the queue
> the check will fail from now on, even if a value of type MyPdu is
> received, because the non-matching value is still as the first
> value in the queue, and the matching is always done against it.
>
>The standard says about the alt construct the following
>(Mockup 20.1.1 Execution of alternative behaviour)
>
> "The test case shall stop and indicate a dynamic error if a test
> component is completely blocked. This means none of the alternatives
> can be chosen, no relevant test component is running, no relevant
> timer is running and all relevant ports contain at least one message,
> call, reply or exception that do not match."
>
>Did I miss something somewhere?
>
>Br
>Antti
>
>
>
>>Regards,
>>Alexey
>>
>>Antti Hyrkkanen wrote:
>>
>>
>>
>>>Hello Alexey & Gyorgy
>>>
>>>I've been wondering what the stand alone .checks are good for.
>>>
>>>If one has a stand-alone .check, how does one know if it failed or not?
>>>One might take a copy of the received values with a stand-alone .check
>>>like in below (example from mockup)
>>>
>>> MyPort.check(getcall(MyProc:{5, MyVar})
>>> from MyPartner -> param (MyPar1Var, MyPar2Var));
>>>
>>>Now, how do I know whether the values of MyPar1Var and MyPar2Var are
>>>undefined or not after the statement?
>>>
>>>Or what if I have the following stand-alone check statement in my module:
>>>
>>> MyPort.check(receive(MyPdu:?));
>>>
>>>If there is a pdu of type MyPdu in the port queue, the check matches
>>>and execution continues. If there is there is not, and no defaults
>>>have been actived, and if the standalone .check is interpreted as a
>>>shorthand for the alt construct as it is said the op-semantics part of
>>>standard, then isn't test component completely blocked in this case,
>>>which causes dynamic error and the testcase to stop.
>>>
>>>Br
>>>Antti
>>>
>>>
>>
>>
>>
>>>

---

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 György Réthy (IJ/ETH)
>>>Sent: Wednesday, February 23, 2005 16:15 PM
>>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>>Subject: Re: Check statement - potential inconsistency
>>>
>>>
>>>Hi Alexey,
>>>
>>>I agree with your comment (the quoted text can be misinterpreted)
>>>and also with the solution you are proposing. Could you pls. send a
>>>CR on this point to ETSI?
>>>
>>>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 Alexey Mednonogov
>>>>Sent: Wednesday, February 23, 2005 1:01 PM
>>>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>>>Subject: Check statement - potential inconsistency
>>>>
>>>>
>>>>Hi!
>>>>
>>>>I have encountered a somewhat obscure phrasing in the current
>>>>TTCN-3 core language standard concerning the 'check' statement,
>>>>
>>>>
>>>>from which it is not immediately appealing whether it has
>>>
>>>
>>>>blocking or non-blocking semantics. The phrasing is (clause
>>>>23.4.0):
>>>>
>>>>"In this case [i.e. if matching criteria are not fullfilled and
>>>>check statement fails - AM] ... the next statement or alternative
>>>>to the check operation is evaluated."
>>>>
>>>>So is it the next statement or is it the next alternative? :)
>>>>
>>>>// Alternatives - example 1:
>>>>
>>>>alt
>>>>{
>>>> [] MyPort1.check { MyNextStatement(); }
>>>> [] MyPort2.receive { Stmts(); }
>>>>}
>>>>
>>>>// Standalone - example 2:
>>>>
>>>>MyPort1.check; // S1
>>>>MyNextStatement(); // S2
>>>>
>>>>From the clause above one may draw a conclusion that in the example 2
>>>>MyNextStatement() (S2) is evaluated after check statement fails, which
>>>>is I guess not the case. According to operational semantics 'check'
>>>>behaves much like 'receive', meaning that statement S1 above
>>>>shall rather
>>>>be re-evaluated if check fails (in the absence of active
>>>>defaults etc).
>>>>
>>>>Proposed solution:
>>>>
>>>>"In this case the copy of the top element of the queue is discarded
>>>>and test execution continues in the same manner as for any other
>>>>receiving operation, i.e. the next alternative to the check operation
>>>>is evaluated. If check is used as a standalone statement, it has
>>>>blocking semantics, i.e. it is considered to be a shorthand for an
>>>>alt statement with the only one alternative."
>>>>
>>>>Best regards,
>>>>Alexey Mednonogov
>>>>OpenTTCN Oy
>>>>
>>>>