Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: about interleave usage

about interleave usage 24 Feb 2003 09:44 #6405

Hi everyone,

two points about the interleave behavior:
(1) why don't we define a timed interleave, namely t-interleave, which can time-guard
the receiving operations in the body. The syntax may be like this:

t-interleave (T) {
[] PCO[1].receive(A)
[] PCO[2].receive(B)
…
[] PCO[n].receive(N)
[] T.timeout { setverdict(fail) }
}

(2) in the last syntax, suppose port1 has received a wrong PDU instead of A,
how can I specify the next action to match this condition? So I think may be we
should additionally define otherwise's for each port receiving operation. The syntax may
be like this:

interleave {
[] PCO[1].receive(A)
?otherwise {do_A} {...}
[] PCO[2].receive(B)
?otherwise {do_B} {...}
…
[] PCO[n].receive(N)
?otherwise {do_N} {...}
}
---
Best Regards,

Zhongjie Li

********************************************************************
* Zhongjie Li *
* Ph.D candidate, Department of Computer Science & Technology *
* Tsinghua University, Beijing, 100084, P.R.China *
* Tel: +86+10-62788109 Fax: +86+10-62788109 *
* Email: This email address is being protected from spambots. You need JavaScript enabled to view it. *
********************************************************************
The administrator has disabled public write access.

about interleave usage 24 Feb 2003 18:06 #6407

Li Zhongjie schrieb:
>
> Hi everyone,
>
> two points about the interleave behavior:
> (1) why don't we define a timed interleave, namely t-interleave, which can
time-guard
> the receiving operations in the body. The syntax may be like this:
>
> t-interleave (T) {
> [] PCO[1].receive(A)
> [] PCO[2].receive(B)
> Â…
> [] PCO[n].receive(N)
> [] T.timeout { setverdict(fail) }
> }
>

Sorry you haven't thought this to the end. The reason for the
restrictions in the
interleave statement is the ability to expand the entire construct into
a set of
nested alt statements, where all interleaved sequences are executed
once.

Allowing guards leads to problems because a receiving operation may
change a guard
related to another receiving operation which may then lead to different
results
depending on how the interleave statement is evaluated.

Allowing control statements leads to a possibly infinite expansion or to
a case
where the interleave is interrupted and the point of interrupt depends
on how the
interleave statement is evaluated.

Your proposal falls into the second category.

When discussing the interleave construct, we could only agree to the
'static'
approach which is implemented in TTCN-3.

Of course it is possible to define a more dynamic
'interleave'-statement, but
we will have a lot of problems in defining a 'deterministic' semantics.


> (2) in the last syntax, suppose port1 has received a wrong PDU instead of A,
> how can I specify the next action to match this condition? So I think may be
we
> should additionally define otherwise's for each port receiving operation. The
syntax may
> be like this:
>
> interleave {
> [] PCO[1].receive(A)
> ?otherwise {do_A} {...}
> [] PCO[2].receive(B)
> ?otherwise {do_B} {...}
> Â…
> [] PCO[n].receive(N)
> ?otherwise {do_N} {...}
> }

You have the TTCN-3 default mechanism for specifying these cases. I
think it
is flexible enough.

Best regards
Jens


> ---
> Best Regards,
>
> Zhongjie Li
>
> ********************************************************************
> * Zhongjie Li *
> * Ph.D candidate, Department of Computer Science & Technology *
> * Tsinghua University, Beijing, 100084, P.R.China *
> * Tel: +86+10-62788109 Fax: +86+10-62788109 *
> * Email: This email address is being protected from spambots. You need JavaScript enabled to view it. *
> ********************************************************************

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin