ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005833 | Part 01: TTCN-3 Core Language | New Feature | public | 29-11-2010 11:34 | 26-09-2011 14:13

Reporter | Jacob Wieland - Spirent |
Assigned To | Ina Schieferdecker |
Priority | low | Severity | major | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.2 (interim 2011) | Fixed in Version | v4.4.1 (published 2012-04) |
Clause Reference(s) | 20.4
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0005833: repeat should be allowed in defaults active during interleave

Description

At the moment, there are quite a few restrictions on the interleave statement which are due to its semantics being defined as a shorthand notation as an alt-statement.
It should be discussed if these restrictions are really necessary or can be removed or at least lessened to an extent that the interleave statement becomes more usable.
For instance, disallowing repeat inside default alternatives active during an interleave statement makes the whole construct unusable in most (or at least a lot) of real-world examples where some messages/events apart from the expected ones which can arrive in any order need to be dropped so they do not block the port queue for the actually expected messages). This is important at least to the 3GPP STF.

Steps To Reproduce |

Additional Information

The meaning of such a use of repeat would be well-defined even in the interleave-as-alt semantics of the interleave statement. The whole currently active alt-statement (which represents the state of all interleave-branches) would be repeated (as for a repeat in an alt-statement).
Of course, it would make sense to lift the ban on repeat in interleave altogether, too (provided one would also allow an if-construct which does not contain any blocking statements - which also would leave the alt-statement semantics intact).
Take the following example:
I want to receive n messages m1 and m messages m2 (where n and m are parameters, both > 0) in any order.
Suppose, you have a helper function like this:
function inc(inout integer v) return integer {
v := v + 1;
return v;
}
Then, at the moment, you would have to do it like this:
var integer receivedM1 := 0, receivedM2 :=0;
while (receivedM1 < n or receivedM2 < m) {
alt {
[receivedM1 < n] p.receive(m1) { inc(receivedM1); }
[receivedM2 < m] p.receive(m2) { inc(receivedM2); }
}
}
With the interleave and repeat you could do it like this:
interleave {
[] p.receive(m1) {
if (inc(receivedM1) < n) { repeat; }
}
[] p.receive(m2) {
if (inc(receivedM2) < m) { repeat; }
}
}
Although the code is not that much shorter, it is not necessary to have an overall condition that needs to be check for every loop
Basically, now it is easy to describe very naturally any interleaving pattern like:
a^n b^m | c^k d^l
where ^x stands for repetition x times and | stands for interleave, while it becomes harder and harder to describe this with pure alt-statements.
Of course, if altsteps were allowed in interleave (which would naturally also not break the alt-statement semantics of interleave), this could be made even easier:
altstep receiveMulti(template T msg,
integer expectedNum,
inout integer received) runs on ... {
[received < expectedNum]
p.receive(msg) {
if (inc(received) < expectedNum) { repeat; }
}
}
interleave {
[] receiveMulti(a, n, receivedA); receiveMulti(b, m, receivedB)
[] receiveMulti(c, k, receivedC); receiveMulti(d, l, receivedC)
}

Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
29-11-2010 11:34 | Jacob Wieland - Spirent | New Issue |
29-11-2010 11:34 | Jacob Wieland - Spirent | Clause Reference(s) | => 20.4
29-11-2010 11:34 | Jacob Wieland - Spirent | Source (company - Author) | => Testing Technologies - Jacob Wieland
29-11-2010 14:27 | Gyorgy Rethy | Status | new => assigned
29-11-2010 14:27 | Gyorgy Rethy | Assigned To | => Jens Grabowski
30-11-2010 09:30 | Jacob Wieland - Spirent | Relationship added | related to 0005807
30-11-2010 09:33 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 15:57 | Gyorgy Rethy | Note Added: 0009856 |
01-12-2010 08:46 | Gyorgy Rethy | Note Edited: 0009856 |
01-12-2010 08:47 | Gyorgy Rethy | Note Edited: 0009856 |
01-12-2010 09:40 | Jens Grabowski | Note Added: 0009874 |
01-12-2010 09:43 | Jens Grabowski | Note Added: 0009875 |
01-12-2010 09:43 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
01-12-2010 10:35 | Jacob Wieland - Spirent | Note Added: 0009883 |
01-12-2010 10:36 | Jacob Wieland - Spirent | Status | assigned => resolved
01-12-2010 10:36 | Jacob Wieland - Spirent | Resolution | open => fixed
01-12-2010 10:37 | Jacob Wieland - Spirent | Status | resolved => feedback
01-12-2010 10:37 | Jacob Wieland - Spirent | Resolution | fixed => reopened
01-12-2010 10:37 | Jacob Wieland - Spirent | Note Added: 0009884 |
01-12-2010 10:37 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
01-12-2010 10:37 | Jacob Wieland - Spirent | Status | feedback => resolved
01-12-2010 10:37 | Jacob Wieland - Spirent | Additional Information Updated |
03-12-2010 10:04 | Gyorgy Rethy | Note Added: 0009935 |
03-12-2010 10:04 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Jens Grabowski
03-12-2010 10:04 | Gyorgy Rethy | Status | resolved => assigned
03-12-2010 10:04 | Gyorgy Rethy | Priority | high => low
03-12-2010 10:04 | Gyorgy Rethy | Resolution | reopened => open
03-12-2010 10:04 | Gyorgy Rethy | Target Version | => Edition 4.3.2 (interim)
26-05-2011 14:41 | Gyorgy Rethy | Relationship deleted | related to 0005807
26-05-2011 14:42 | Gyorgy Rethy | Status | assigned => closed
26-05-2011 14:42 | Gyorgy Rethy | Note Added: 0010089 |
26-05-2011 14:42 | Gyorgy Rethy | Resolution | open => fixed
26-05-2011 14:42 | Gyorgy Rethy | Fixed in Version | => Edition 4.3.1 (not yet published)
01-08-2011 11:33 | Gyorgy Rethy | Assigned To | Jens Grabowski => Ina Schieferdecker
01-08-2011 11:33 | Gyorgy Rethy | Status | closed => feedback
01-08-2011 11:33 | Gyorgy Rethy | Resolution | fixed => reopened
01-08-2011 11:33 | Gyorgy Rethy | Note Added: 0010233 |
26-09-2011 14:13 | Ina Schieferdecker | Note Added: 0010234 |
26-09-2011 14:13 | Ina Schieferdecker | Status | feedback => closed
26-09-2011 14:13 | Ina Schieferdecker | Resolution | reopened => fixed
26-09-2011 14:13 | Ina Schieferdecker | Fixed in Version | Edition 4.3.1 => Edition 4.4.1

Notes

(0009856)
Gyorgy Rethy
30-11-2010 15:57 (edited on: 01-12-2010 08:47)

STF discussion on 30-11-2010: repeat is allowed in activated defaults.Add a note clarifying this to Part-1 v4.3.1. All other possible changes to interleave is postponed to 2011.

(0009874)
Jens Grabowski
01-12-2010 09:40

I propose the following resolution:
Change Note 1 in 20.5.1 from
"NOTE 1: An interleave statement is semantically equivalent to a nested set of alt statements and the default mechanism also applies to each of these alt statements. This means, the default mechanism also applies to interleave statements."
to
"NOTE 1: An interleave statement is semantically equivalent to a nested set of alt statements and the default mechanism also applies to each of these alt statements. This means, the default mechanism also applies to interleave statements. Furthermore, the restrictions imposed on interleave statements in Clause 20.4 do not apply to altsteps that are activated as default behaviour for interleave statements."

(0009875)
Jens Grabowski
01-12-2010 09:43

Jacob, please proofread proposal.

(0009883)
Jacob Wieland - Spirent
01-12-2010 10:35

Proposal is fine.

(0009884)
Jacob Wieland - Spirent
01-12-2010 10:37

ina, please set this to resolved

(0009935)
Gyorgy Rethy
03-12-2010 10:04

Discussion on interleave restrictions is postponed to 2011, in v4.3.1 only use of repeat in activated defaults has to be clarified.

(0010089)
Gyorgy Rethy
26-05-2011 14:42

Implemented.

(0010233)
Gyorgy Rethy
01-08-2011 11:33

Addition to Note1 of $20.5.1 is missing in v4.3.1 (and therefore from v4.3.2)

(0010234)
Ina Schieferdecker
26-09-2011 14:13

I was taking the note by Jacob literally to close the CR ;-) Note is now extended as proposed.