TOPIC:

Hello,

I would like to share with you the following situation, encountered while working with parallel components and to kindly ask for your opinion on this.
I have the following flow in the test case, using two created components, c_cmComp and c_canComp.
I have described below also the functions sync() and syncCompBehavior().

The problem appears inside the f_HDD_MP3() function, running on c_cmComp. When performing sync() twice, I'm expecting for the c_cmComp to stop and to run the behavior on c_canComp. Unfortunately, this thing happens only when performing double sync() for the first time. On the second try, the behavior remains on the c_cmComp which calls twice sync. Is this behavior normal?

********************************************
c_cmComp.start(f_HDD_MP3());

c_canComp.start (f_RunDown());

syncCompBehavior(2);

**********************************************

function sync() runs on SyncComp {
p_sync.send (SyncRequest: {});
p_sync.receive (SyncResponse: {});
}
**************************************************

function syncCompBehavior(integer n) runs on SyncComp {

var SyncCompList listOfSenders;

var integer i := 0;

alt {

[] p_sync.receive (

SyncRequest: {}) -> sender listOfSenders {

i := i + 1;

if (i < n) {

repeat;

} else {

for (i := 0; i < n; i := i + 1) {

p_sync.send (SyncResponse: {}) to valueof(listOfSenders);

}

i := 0;

repeat;

}

}

[] all component.done {};

}

}

..........................................................
Mit freundlichem Gruß / Kind regards
Alina Maria Luca
Siemens VDO Automotive
SV I IS RD AD IAS SW TA
B-dul Poitiers no. 10
700671 Iasi
Romania
Tel. +40 (256) 30 - 7029
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.

Hello Alina

Can you be more specific on the execution flows within
the two functions that you execute in the parallel components?
How and when they call sync(), and what they do after that.

// Antti Hyrkkänen @ Plenware
// www.plenware.fi/en

>

---

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 Luca, Alina
> Sent: 17. elokuuta 2007 11:51
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Parallel components running
>
>
> Hello,
>
> I would like to share with you the following situation, encountered while
> working with parallel components and to kindly ask for your opinion on this.
> I have the following flow in the test case, using two created components,
> c_cmComp and c_canComp.
> I have described below also the functions sync() and syncCompBehavior().
>
> The problem appears inside the f_HDD_MP3() function, running on c_cmComp.
> When performing sync() twice, I'm expecting for the c_cmComp to stop and to
> run the behavior on c_canComp. Unfortunately, this thing happens only when
> performing double sync() for the first time. On the second try, the behavior
> remains on the c_cmComp which calls twice sync. Is this behavior normal?
>
> ********************************************
> c_cmComp.start(f_HDD_MP3());
>
> c_canComp.start (f_RunDown());
>
> syncCompBehavior(2);
>
> **********************************************
>
> function sync() runs on SyncComp {
> p_sync.send (SyncRequest: {});
> p_sync.receive (SyncResponse: {});
> }
> **************************************************
>
> function syncCompBehavior(integer n) runs on SyncComp {
>
> var SyncCompList listOfSenders;
>
> var integer i := 0;
>
> alt {
>
> [] p_sync.receive (
>
> SyncRequest: {}) -> sender listOfSenders {
>
> i := i + 1;
>
> if (i < n) {
>
> repeat;
>
> } else {
>
> for (i := 0; i < n; i := i + 1) {
>
> p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
>
> }
>
> i := 0;
>
> repeat;
>
> }
>
> }
>
> [] all component.done {};
>
> }
>
> }
>
> ..........................................................
> Mit freundlichem Gruß / Kind regards
> Alina Maria Luca
> Siemens VDO Automotive
> SV I IS RD AD IAS SW TA
> B-dul Poitiers no. 10
> 700671 Iasi
> Romania
> Tel. +40 (256) 30 - 7029
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.

Hi Alina,

See comments inline

>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 10:51
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Parallel components running
>
>
> Hello,
>
> I would like to share with you the following situation,
> encountered while working with parallel components and to
> kindly ask for your opinion on this.
> I have the following flow in the test case, using two created
> components, c_cmComp and c_canComp.
> I have described below also the functions sync() and
> syncCompBehavior().
>
> The problem appears inside the f_HDD_MP3() function, running
> on c_cmComp. When performing sync() twice, I'm expecting for
> the c_cmComp to stop and to run the behavior on c_canComp.

You have not provided any information about what is inside of this f_HDD_MP3() behavior. If it indeed calls sync() twice that will cause the component (the MTC???) running the syncCompBehavior() in the first code block to leave the function's body. It has no effects on the execution state of c_canComp.

> Unfortunately, this thing happens only when performing double
> sync() for the first time. On the second try, the behavior
> remains on the c_cmComp which calls twice sync. Is this
> behavior normal?
>

Your problem description is under-defined, at least for me.

I suppose that the first block of code is running on neither c_cmComp nor c_CanComp, since you have stated that both are "created". Possibly it is some "c_syncComp" of type SyncComp, or of a component type that extends SyncComp. I suppose that this is the MTC.

> ********************************************
> c_cmComp.start(f_HDD_MP3());
>
> c_canComp.start (f_RunDown());
>
> syncCompBehavior(2);
>
> **********************************************
The semantics of the above code (supposing that "c_syncComp" is the component that executes)
1. c_syncComp instructs c_cmComp to run the behavior f_HDD_MP3. This is a non-blocking statement for "c_syncComp", that is, its execution immediately continues, without waiting for c_cmComp to actually start. Furthermore as soon as c_cmComp finishes the execution of f_HDD_MP3 it will die (unless you have created this as an "alive" component)

2. c_syncComp instructs c_canComp to run the behavior f_RunDown. This is a non-blocking statement for "c_syncComp", that is, its execution immediately continues, without waiting for c_canComp to actually start. Furthermore as soon as c_canComp finishes the execution of f_RunDown it will die (unless you have created this as an "alive" component)

3. Now at least three components are already running in parallel and independently from each other (without bothering with any "sync" operation of yours!) in your Test System: c_cmComp, c_canComp, c_syncComp

4. c_syncComp enters syncCompBehavior, with the actual argument of 2. Inside the function there is an alt statement, which is a blocking statement. It will leave the alt upon either of the conditions:
4.1 It has received SyncRequest from any component at least twice. The sender could be two different components or it could be the same component twice
4.2 All PTC except the MTC has been finished. If c_syncComp is not the MTC this condition will never be matched.

If any of the conditions is met then execution will leave the syncCompBehavior. If this is the MTC and no further code is given to be executed to this MTC then this MTC component will stop causing all other PTC to be killed instantly regardless of their execution state.

As a summary: your problem description needs some clarification or I have misunderstood something ;)

Best regards,



Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center

Ericsson Hungary Ltd.

Research & Development
Budapest, XI. Irinyi. J. u. 4-20.
www.ericsson.com

Office: +36 1 437 7361
Fax: +36 1 439 5176
Mobile: +30 30 219 9805
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1. Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám: 01-09-070937

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


>
> function sync() runs on SyncComp {
> p_sync.send (SyncRequest: {});
> p_sync.receive (SyncResponse: {});
> }
> **************************************************
>
> function syncCompBehavior(integer n) runs on SyncComp {
>
> var SyncCompList listOfSenders;
>
> var integer i := 0;
>
> alt {
>
> [] p_sync.receive (
>
> SyncRequest: {}) -> sender listOfSenders {
>
> i := i + 1;
>
> if (i < n) {
>
> repeat;
>
> } else {
>
> for (i := 0; i < n; i := i + 1) {
>
> p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
>
> }
>
> i := 0;
>
> repeat;
>
> }
>
> }
>
> [] all component.done {};
>
> }
>
> }
>
> ..........................................................
> Mit freundlichem Gruß / Kind regards
> Alina Maria Luca
> Siemens VDO Automotive
> SV I IS RD AD IAS SW TA
> B-dul Poitiers no. 10
> 700671 Iasi
> Romania
> Tel. +40 (256) 30 - 7029
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> <blocked::mailto:alina.luca@siemens.com>
>

I will try to explain better.

Test case is running on a component called testComponent. After that I created the next two compoenents:

var cmComp c_cmComp := cmComp.create;
var CANComp c_canComp := CANComp.create;

connect (c_cmComp: p_sync, mtc: p_sync);
connect (c_canComp: p_sync, mtc: p_sync);

map (c_cmComp: InOutPort, system: InOutPort);
map (c_canComp:canP, system:canP);

after that we have the main flow:

c_cmComp.start(f_HDD_MP3());
c_canComp.start (f_RunDown());
syncCompBehavior(2);
all component.done;


The functions sync () and syncCompBehavior() are described below.

The f_RunDown() has the following content:

function f_RunDown()runs on CANComp
{

sync();
f_CanSetUp();
******************************************send statement
canTGuard.start;

************ alt block
{

}
canP.send(CanMessageId(1397,'00000000'O));
canP.send(CanMessageId(707,'00'O));
canTGuard.start;

*********** alt block
{

}

f_RunUp();
sync();
sync();

}


Now, f_HDD_MP3() looks like this:

function f_HDD_MP3() runs on cmComp{

********************** send/receive statements

sync();
sync();

********************** send/receive statements

sync();
sync();

********************** send/receive statements

sync();

}

---

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 Gábor Ziegler (IJ/ETH)
Sent: Friday, August 17, 2007 12:39 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running

Hi Alina,

See comments inline

>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 10:51
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Parallel components running
>
>
> Hello,
>
> I would like to share with you the following situation,
> encountered while working with parallel components and to
> kindly ask for your opinion on this.
> I have the following flow in the test case, using two created
> components, c_cmComp and c_canComp.
> I have described below also the functions sync() and
> syncCompBehavior().
>
> The problem appears inside the f_HDD_MP3() function, running
> on c_cmComp. When performing sync() twice, I'm expecting for
> the c_cmComp to stop and to run the behavior on c_canComp.

You have not provided any information about what is inside of this f_HDD_MP3() behavior. If it indeed calls sync() twice that will cause the component (the MTC???) running the syncCompBehavior() in the first code block to leave the function's body. It has no effects on the execution state of c_canComp.

> Unfortunately, this thing happens only when performing double
> sync() for the first time. On the second try, the behavior
> remains on the c_cmComp which calls twice sync. Is this
> behavior normal?
>

Your problem description is under-defined, at least for me.

I suppose that the first block of code is running on neither c_cmComp nor c_CanComp, since you have stated that both are "created". Possibly it is some "c_syncComp" of type SyncComp, or of a component type that extends SyncComp. I suppose that this is the MTC.

> ********************************************
> c_cmComp.start(f_HDD_MP3());
>
> c_canComp.start (f_RunDown());
>
> syncCompBehavior(2);
>
> **********************************************
The semantics of the above code (supposing that "c_syncComp" is the component that executes)
1. c_syncComp instructs c_cmComp to run the behavior f_HDD_MP3. This is a non-blocking statement for "c_syncComp", that is, its execution immediately continues, without waiting for c_cmComp to actually start. Furthermore as soon as c_cmComp finishes the execution of f_HDD_MP3 it will die (unless you have created this as an "alive" component)

2. c_syncComp instructs c_canComp to run the behavior f_RunDown. This is a non-blocking statement for "c_syncComp", that is, its execution immediately continues, without waiting for c_canComp to actually start. Furthermore as soon as c_canComp finishes the execution of f_RunDown it will die (unless you have created this as an "alive" component)

3. Now at least three components are already running in parallel and independently from each other (without bothering with any "sync" operation of yours!) in your Test System: c_cmComp, c_canComp, c_syncComp

4. c_syncComp enters syncCompBehavior, with the actual argument of 2. Inside the function there is an alt statement, which is a blocking statement. It will leave the alt upon either of the conditions:
4.1 It has received SyncRequest from any component at least twice. The sender could be two different components or it could be the same component twice
4.2 All PTC except the MTC has been finished. If c_syncComp is not the MTC this condition will never be matched.

If any of the conditions is met then execution will leave the syncCompBehavior. If this is the MTC and no further code is given to be executed to this MTC then this MTC component will stop causing all other PTC to be killed instantly regardless of their execution state.

As a summary: your problem description needs some clarification or I have misunderstood something ;)

Best regards,



Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center

Ericsson Hungary Ltd.

Research & Development
Budapest, XI. Irinyi. J. u. 4-20.
www.ericsson.com

Office: +36 1 437 7361
Fax: +36 1 439 5176
Mobile: +30 30 219 9805
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1. Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám: 01-09-070937

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


>
> function sync() runs on SyncComp {
> p_sync.send (SyncRequest: {});
> p_sync.receive (SyncResponse: {});
> }
> **************************************************
>
> function syncCompBehavior(integer n) runs on SyncComp {
>
> var SyncCompList listOfSenders;
>
> var integer i := 0;
>
> alt {
>
> [] p_sync.receive (
>
> SyncRequest: {}) -> sender listOfSenders {
>
> i := i + 1;
>
> if (i < n) {
>
> repeat;
>
> } else {
>
> for (i := 0; i < n; i := i + 1) {
>
> p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
>
> }
>
> i := 0;
>
> repeat;
>
> }
>
> }
>
> [] all component.done {};
>
> }
>
> }
>
> ..........................................................
> Mit freundlichem Gruß / Kind regards
> Alina Maria Luca
> Siemens VDO Automotive
> SV I IS RD AD IAS SW TA
> B-dul Poitiers no. 10
> 700671 Iasi
> Romania
> Tel. +40 (256) 30 - 7029
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> <blocked::mailto:alina.luca@siemens.com>
>

Hi Alina,

Inspect your code in parallel: f_RunDown has only 3 syncs, while f_HDD_MP3 has 5

function f_RunDown()runs on CANComp

{



//1st sync======
sync();

f_CanSetUp();

***send statement

canTGuard.start;

*** alt block

{

}

canP.send(CanMessageId(1397,'00000000'O));

canP.send(CanMessageId(707,'00'O));

canTGuard.start;

**** alt block

{

}

f_RunUp();

//2nd sync=====
sync();





//3rd sync======
sync();

}





function f_HDD_MP3() runs on cmComp{

********************** send/receive statements

//1st sync======
sync();































//2nd sync===
sync();

********************** send/receive statements

//3rd sync=====
sync();

//4th sync =====
//would block forever
sync();

********************** send/receive statements

//5th sync=====
sync();

}







Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center
IJ/ETH

Ericsson Hungary Ltd.
Research & Development
ECN: 831 7361
Web: mwlx122.eth.ericsson.se:8081/~egbozie



>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 11:55
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> I will try to explain better.
>
> Test case is running on a component called testComponent.
> After that I created the next two compoenents:
>
> var cmComp c_cmComp := cmComp.create;
> var CANComp c_canComp := CANComp.create;
>
> connect (c_cmComp: p_sync, mtc: p_sync);
> connect (c_canComp: p_sync, mtc: p_sync);
>
> map (c_cmComp: InOutPort, system: InOutPort);
> map (c_canComp:canP, system:canP);
>
> after that we have the main flow:
>
> c_cmComp.start(f_HDD_MP3());
> c_canComp.start (f_RunDown());
> syncCompBehavior(2);
> all component.done;
>
>
> The functions sync () and syncCompBehavior() are described below.
>
> The f_RunDown() has the following content:
>
> function f_RunDown()runs on CANComp
> {
>
> sync();
> f_CanSetUp();
> ******************************************send statement
> canTGuard.start;
>
> ************ alt block
> {
>
> }
> canP.send(CanMessageId(1397,'00000000'O));
> canP.send(CanMessageId(707,'00'O));
> canTGuard.start;
>
> *********** alt block
> {
>
> }
>
> f_RunUp();
> sync();
> sync();
>
> }
>
>
> Now, f_HDD_MP3() looks like this:
>
> function f_HDD_MP3() runs on cmComp{
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
>
> }
>
>

---

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 Gábor
> Ziegler (IJ/ETH)
> Sent: Friday, August 17, 2007 12:39 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> Hi Alina,
>
> See comments inline
>
> >

---

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 Luca, Alina
> > Sent: 2007. augusztus 17. 10:51
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Parallel components running
> >
> >
> > Hello,
> >
> > I would like to share with you the following situation,
> > encountered while working with parallel components and to
> > kindly ask for your opinion on this.
> > I have the following flow in the test case, using two created
> > components, c_cmComp and c_canComp.
> > I have described below also the functions sync() and
> > syncCompBehavior().
> >
> > The problem appears inside the f_HDD_MP3() function, running
> > on c_cmComp. When performing sync() twice, I'm expecting for
> > the c_cmComp to stop and to run the behavior on c_canComp.
>
> You have not provided any information about what is inside of
> this f_HDD_MP3() behavior. If it indeed calls sync() twice
> that will cause the component (the MTC???) running the
> syncCompBehavior() in the first code block to leave the
> function's body. It has no effects on the execution state of
> c_canComp.
>
> > Unfortunately, this thing happens only when performing double
> > sync() for the first time. On the second try, the behavior
> > remains on the c_cmComp which calls twice sync. Is this
> > behavior normal?
> >
>
> Your problem description is under-defined, at least for me.
>
> I suppose that the first block of code is running on neither
> c_cmComp nor c_CanComp, since you have stated that both are
> "created". Possibly it is some "c_syncComp" of type SyncComp,
> or of a component type that extends SyncComp. I suppose that
> this is the MTC.
>
> > ********************************************
> > c_cmComp.start(f_HDD_MP3());
> >
> > c_canComp.start (f_RunDown());
> >
> > syncCompBehavior(2);
> >
> > **********************************************
> The semantics of the above code (supposing that "c_syncComp"
> is the component that executes)
> 1. c_syncComp instructs c_cmComp to run the behavior
> f_HDD_MP3. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_cmComp to actually start. Furthermore as soon as
> c_cmComp finishes the execution of f_HDD_MP3 it will die
> (unless you have created this as an "alive" component)
>
> 2. c_syncComp instructs c_canComp to run the behavior
> f_RunDown. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_canComp to actually start. Furthermore as soon as
> c_canComp finishes the execution of f_RunDown it will die
> (unless you have created this as an "alive" component)
>
> 3. Now at least three components are already running in
> parallel and independently from each other (without
> bothering with any "sync" operation of yours!) in your Test
> System: c_cmComp, c_canComp, c_syncComp
>
> 4. c_syncComp enters syncCompBehavior, with the actual
> argument of 2. Inside the function there is an alt statement,
> which is a blocking statement. It will leave the alt upon
> either of the conditions:
> 4.1 It has received SyncRequest from any component at least
> twice. The sender could be two different components or it
> could be the same component twice
> 4.2 All PTC except the MTC has been finished. If c_syncComp
> is not the MTC this condition will never be matched.
>
> If any of the conditions is met then execution will leave the
> syncCompBehavior. If this is the MTC and no further code is
> given to be executed to this MTC then this MTC component will
> stop causing all other PTC to be killed instantly regardless
> of their execution state.
>
> As a summary: your problem description needs some
> clarification or I have misunderstood something ;)
>
> Best regards,
>
>
>
> Gábor Ziegler M.Sc.E.E., dr.univ
> Test System Engineer
> Test Competence Center
>
> Ericsson Hungary Ltd.
>
> Research & Development
> Budapest, XI. Irinyi. J. u. 4-20.
> www.ericsson.com
>
> Office: +36 1 437 7361
> Fax: +36 1 439 5176
> Mobile: +30 30 219 9805
> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1.
> Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám:
> 01-09-070937
>
> This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data
> corruption, interception, unauthorized amendment, tampering
> and viruses, and we only send and receive emails on the basis
> that we are not liable for any such corruption, interception,
> amendment, tampering or viruses or any consequences thereof.
>
>
> >
> > function sync() runs on SyncComp {
> > p_sync.send (SyncRequest: {});
> > p_sync.receive (SyncResponse: {});
> > }
> > **************************************************
> >
> > function syncCompBehavior(integer n) runs on SyncComp {
> >
> > var SyncCompList listOfSenders;
> >
> > var integer i := 0;
> >
> > alt {
> >
> > [] p_sync.receive (
> >
> > SyncRequest: {}) -> sender listOfSenders {
> >
> > i := i + 1;
> >
> > if (i < n) {
> >
> > repeat;
> >
> > } else {
> >
> > for (i := 0; i < n; i := i + 1) {
> >
> > p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
> >
> > }
> >
> > i := 0;
> >
> > repeat;
> >
> > }
> >
> > }
> >
> > [] all component.done {};
> >
> > }
> >
> > }
> >
> > ..........................................................
> > Mit freundlichem Gruß / Kind regards
> > Alina Maria Luca
> > Siemens VDO Automotive
> > SV I IS RD AD IAS SW TA
> > B-dul Poitiers no. 10
> > 700671 Iasi
> > Romania
> > Tel. +40 (256) 30 - 7029
> > E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > <blocked::mailto:alina.luca@siemens.com>
> >
>

Yes, but on f_HDD_MP3() I have used double sync instruction
sync();
sync();

In order to block actual compenent and to run the other one only.

Is this correct?


________________________________

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 Gábor Ziegler (IJ/ETH)
Sent: Friday, August 17, 2007 1:30 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running


Hi Alina,

Inspect your code in parallel: f_RunDown has only 3 syncs, while f_HDD_MP3 has 5

function f_RunDown()runs on CANComp

{



//1st sync======
sync();

f_CanSetUp();

***send statement

canTGuard.start;

*** alt block

{

}

canP.send(CanMessageId(1397,'00000000'O));

canP.send(CanMessageId(707,'00'O));

canTGuard.start;

**** alt block

{

}

f_RunUp();

//2nd sync=====
sync();





//3rd sync======
sync();

}





function f_HDD_MP3() runs on cmComp{

********************** send/receive statements

//1st sync======
sync();

here is double sync:

sync();

sync();





















//2nd sync===
sync();

here is double sync:

sync();

sync();

********************** send/receive statements

//3rd sync=====
sync();

//4th sync =====
//would block forever
sync();

********************** send/receive statements

//5th sync=====
sync();

}







Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center
IJ/ETH

Ericsson Hungary Ltd.
Research & Development
ECN: 831 7361
Web: mwlx122.eth.ericsson.se:8081/~egbozie



>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 11:55
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> I will try to explain better.
>
> Test case is running on a component called testComponent.
> After that I created the next two compoenents:
>
> var cmComp c_cmComp := cmComp.create;
> var CANComp c_canComp := CANComp.create;
>
> connect (c_cmComp: p_sync, mtc: p_sync);
> connect (c_canComp: p_sync, mtc: p_sync);
>
> map (c_cmComp: InOutPort, system: InOutPort);
> map (c_canComp:canP, system:canP);
>
> after that we have the main flow:
>
> c_cmComp.start(f_HDD_MP3());
> c_canComp.start (f_RunDown());
> syncCompBehavior(2);
> all component.done;
>
>
> The functions sync () and syncCompBehavior() are described below.
>
> The f_RunDown() has the following content:
>
> function f_RunDown()runs on CANComp
> {
>
> sync();
> f_CanSetUp();
> ******************************************send statement
> canTGuard.start;
>
> ************ alt block
> {
>
> }
> canP.send(CanMessageId(1397,'00000000'O));
> canP.send(CanMessageId(707,'00'O));
> canTGuard.start;
>
> *********** alt block
> {
>
> }
>
> f_RunUp();
> sync();
> sync();
>
> }
>
>
> Now, f_HDD_MP3() looks like this:
>
> function f_HDD_MP3() runs on cmComp{
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
>
> }
>
>

---

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 Gábor
> Ziegler (IJ/ETH)
> Sent: Friday, August 17, 2007 12:39 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> Hi Alina,
>
> See comments inline
>
> >

---

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 Luca, Alina
> > Sent: 2007. augusztus 17. 10:51
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Parallel components running
> >
> >
> > Hello,
> >
> > I would like to share with you the following situation,
> > encountered while working with parallel components and to
> > kindly ask for your opinion on this.
> > I have the following flow in the test case, using two created
> > components, c_cmComp and c_canComp.
> > I have described below also the functions sync() and
> > syncCompBehavior().
> >
> > The problem appears inside the f_HDD_MP3() function, running
> > on c_cmComp. When performing sync() twice, I'm expecting for
> > the c_cmComp to stop and to run the behavior on c_canComp.
>
> You have not provided any information about what is inside of
> this f_HDD_MP3() behavior. If it indeed calls sync() twice
> that will cause the component (the MTC???) running the
> syncCompBehavior() in the first code block to leave the
> function's body. It has no effects on the execution state of
> c_canComp.
>
> > Unfortunately, this thing happens only when performing double
> > sync() for the first time. On the second try, the behavior
> > remains on the c_cmComp which calls twice sync. Is this
> > behavior normal?
> >
>
> Your problem description is under-defined, at least for me.
>
> I suppose that the first block of code is running on neither
> c_cmComp nor c_CanComp, since you have stated that both are
> "created". Possibly it is some "c_syncComp" of type SyncComp,
> or of a component type that extends SyncComp. I suppose that
> this is the MTC.
>
> > ********************************************
> > c_cmComp.start(f_HDD_MP3());
> >
> > c_canComp.start (f_RunDown());
> >
> > syncCompBehavior(2);
> >
> > **********************************************
> The semantics of the above code (supposing that "c_syncComp"
> is the component that executes)
> 1. c_syncComp instructs c_cmComp to run the behavior
> f_HDD_MP3. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_cmComp to actually start. Furthermore as soon as
> c_cmComp finishes the execution of f_HDD_MP3 it will die
> (unless you have created this as an "alive" component)
>
> 2. c_syncComp instructs c_canComp to run the behavior
> f_RunDown. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_canComp to actually start. Furthermore as soon as
> c_canComp finishes the execution of f_RunDown it will die
> (unless you have created this as an "alive" component)
>
> 3. Now at least three components are already running in
> parallel and independently from each other (without
> bothering with any "sync" operation of yours!) in your Test
> System: c_cmComp, c_canComp, c_syncComp
>
> 4. c_syncComp enters syncCompBehavior, with the actual
> argument of 2. Inside the function there is an alt statement,
> which is a blocking statement. It will leave the alt upon
> either of the conditions:
> 4.1 It has received SyncRequest from any component at least
> twice. The sender could be two different components or it
> could be the same component twice
> 4.2 All PTC except the MTC has been finished. If c_syncComp
> is not the MTC this condition will never be matched.
>
> If any of the conditions is met then execution will leave the
> syncCompBehavior. If this is the MTC and no further code is
> given to be executed to this MTC then this MTC component will
> stop causing all other PTC to be killed instantly regardless
> of their execution state.
>
> As a summary: your problem description needs some
> clarification or I have misunderstood something ;)
>
> Best regards,
>
>
>
> Gábor Ziegler M.Sc.E.E., dr.univ
> Test System Engineer
> Test Competence Center
>
> Ericsson Hungary Ltd.
>
> Research & Development
> Budapest, XI. Irinyi. J. u. 4-20.
> www.ericsson.com
>
> Office: +36 1 437 7361
> Fax: +36 1 439 5176
> Mobile: +30 30 219 9805
> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1.
> Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám:
> 01-09-070937
>
> This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data
> corruption, interception, unauthorized amendment, tampering
> and viruses, and we only send and receive emails on the basis
> that we are not liable for any such corruption, interception,
> amendment, tampering or viruses or any consequences thereof.
>
>
> >
> > function sync() runs on SyncComp {
> > p_sync.send (SyncRequest: {});
> > p_sync.receive (SyncResponse: {});
> > }
> > **************************************************
> >
> > function syncCompBehavior(integer n) runs on SyncComp {
> >
> > var SyncCompList listOfSenders;
> >
> > var integer i := 0;
> >
> > alt {
> >
> > [] p_sync.receive (
> >
> > SyncRequest: {}) -> sender listOfSenders {
> >
> > i := i + 1;
> >
> > if (i < n) {
> >
> > repeat;
> >
> > } else {
> >
> > for (i := 0; i < n; i := i + 1) {
> >
> > p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
> >
> > }
> >
> > i := 0;
> >
> > repeat;
> >
> > }
> >
> > }
> >
> > [] all component.done {};
> >
> > }
> >
> > }
> >
> > ..........................................................
> > Mit freundlichem Gruß / Kind regards
> > Alina Maria Luca
> > Siemens VDO Automotive
> > SV I IS RD AD IAS SW TA
> > B-dul Poitiers no. 10
> > 700671 Iasi
> > Romania
> > Tel. +40 (256) 30 - 7029
> > E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > <blocked::mailto:alina.luca@siemens.com>
> >
>

Hi, Alina,

With your sync() implementation you can never execute "double" sync alone, since the first sync of the double-sync would block until the other component performs a sync and the second-sync of the double-sync would block until the other component performs again a sync.

That is, with your sync() implementation you cannot sync to yourself, only to some other component.

With your sync(), the number of sync() function calls must be equal in both components. If not, than the component with more sync() calls will be stuck forever eventually. In the example below, f_RunDown has 3 three calls to sync(), while f_HDD_MP3() has 5. That is, f_HDD_MP3() will be deadlocked in its (3+1)th sync() call forever, because its peer-component never performs its fourth sync (it has been "done" some times after its third sync())

BR,
Gabor





________________________________

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 Luca, Alina
Sent: 2007. augusztus 17. 12:41
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running


Yes, but on f_HDD_MP3() I have used double sync instruction
sync();
sync();

In order to block actual compenent and to run the other one only.

Is this correct?


________________________________

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 Gábor Ziegler (IJ/ETH)
Sent: Friday, August 17, 2007 1:30 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running


Hi Alina,

Inspect your code in parallel: f_RunDown has only 3 syncs, while f_HDD_MP3 has 5

function f_RunDown()runs on CANComp

{



//1st sync======
sync();

f_CanSetUp();

***send statement

canTGuard.start;

*** alt block

{

}

canP.send(CanMessageId(1397,'00000000'O));

canP.send(CanMessageId(707,'00'O));

canTGuard.start;

**** alt block

{

}

f_RunUp();

//2nd sync=====
sync();





//3rd sync======
sync();

}





function f_HDD_MP3() runs on cmComp{

********************** send/receive statements

//1st sync======
sync();

here is double sync:

sync();

sync();





















//2nd sync===
sync();

here is double sync:

sync();

sync();

********************** send/receive statements

//3rd sync=====
sync();

//4th sync =====
//would block forever
sync();

********************** send/receive statements

//5th sync=====
sync();

}







Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center
IJ/ETH

Ericsson Hungary Ltd.
Research & Development
ECN: 831 7361
Web: mwlx122.eth.ericsson.se:8081/~egbozie



>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 11:55
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> I will try to explain better.
>
> Test case is running on a component called testComponent.
> After that I created the next two compoenents:
>
> var cmComp c_cmComp := cmComp.create;
> var CANComp c_canComp := CANComp.create;
>
> connect (c_cmComp: p_sync, mtc: p_sync);
> connect (c_canComp: p_sync, mtc: p_sync);
>
> map (c_cmComp: InOutPort, system: InOutPort);
> map (c_canComp:canP, system:canP);
>
> after that we have the main flow:
>
> c_cmComp.start(f_HDD_MP3());
> c_canComp.start (f_RunDown());
> syncCompBehavior(2);
> all component.done;
>
>
> The functions sync () and syncCompBehavior() are described below.
>
> The f_RunDown() has the following content:
>
> function f_RunDown()runs on CANComp
> {
>
> sync();
> f_CanSetUp();
> ******************************************send statement
> canTGuard.start;
>
> ************ alt block
> {
>
> }
> canP.send(CanMessageId(1397,'00000000'O));
> canP.send(CanMessageId(707,'00'O));
> canTGuard.start;
>
> *********** alt block
> {
>
> }
>
> f_RunUp();
> sync();
> sync();
>
> }
>
>
> Now, f_HDD_MP3() looks like this:
>
> function f_HDD_MP3() runs on cmComp{
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
>
> }
>
>

---

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 Gábor
> Ziegler (IJ/ETH)
> Sent: Friday, August 17, 2007 12:39 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> Hi Alina,
>
> See comments inline
>
> >

---

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 Luca, Alina
> > Sent: 2007. augusztus 17. 10:51
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Parallel components running
> >
> >
> > Hello,
> >
> > I would like to share with you the following situation,
> > encountered while working with parallel components and to
> > kindly ask for your opinion on this.
> > I have the following flow in the test case, using two created
> > components, c_cmComp and c_canComp.
> > I have described below also the functions sync() and
> > syncCompBehavior().
> >
> > The problem appears inside the f_HDD_MP3() function, running
> > on c_cmComp. When performing sync() twice, I'm expecting for
> > the c_cmComp to stop and to run the behavior on c_canComp.
>
> You have not provided any information about what is inside of
> this f_HDD_MP3() behavior. If it indeed calls sync() twice
> that will cause the component (the MTC???) running the
> syncCompBehavior() in the first code block to leave the
> function's body. It has no effects on the execution state of
> c_canComp.
>
> > Unfortunately, this thing happens only when performing double
> > sync() for the first time. On the second try, the behavior
> > remains on the c_cmComp which calls twice sync. Is this
> > behavior normal?
> >
>
> Your problem description is under-defined, at least for me.
>
> I suppose that the first block of code is running on neither
> c_cmComp nor c_CanComp, since you have stated that both are
> "created". Possibly it is some "c_syncComp" of type SyncComp,
> or of a component type that extends SyncComp. I suppose that
> this is the MTC.
>
> > ********************************************
> > c_cmComp.start(f_HDD_MP3());
> >
> > c_canComp.start (f_RunDown());
> >
> > syncCompBehavior(2);
> >
> > **********************************************
> The semantics of the above code (supposing that "c_syncComp"
> is the component that executes)
> 1. c_syncComp instructs c_cmComp to run the behavior
> f_HDD_MP3. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_cmComp to actually start. Furthermore as soon as
> c_cmComp finishes the execution of f_HDD_MP3 it will die
> (unless you have created this as an "alive" component)
>
> 2. c_syncComp instructs c_canComp to run the behavior
> f_RunDown. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_canComp to actually start. Furthermore as soon as
> c_canComp finishes the execution of f_RunDown it will die
> (unless you have created this as an "alive" component)
>
> 3. Now at least three components are already running in
> parallel and independently from each other (without
> bothering with any "sync" operation of yours!) in your Test
> System: c_cmComp, c_canComp, c_syncComp
>
> 4. c_syncComp enters syncCompBehavior, with the actual
> argument of 2. Inside the function there is an alt statement,
> which is a blocking statement. It will leave the alt upon
> either of the conditions:
> 4.1 It has received SyncRequest from any component at least
> twice. The sender could be two different components or it
> could be the same component twice
> 4.2 All PTC except the MTC has been finished. If c_syncComp
> is not the MTC this condition will never be matched.
>
> If any of the conditions is met then execution will leave the
> syncCompBehavior. If this is the MTC and no further code is
> given to be executed to this MTC then this MTC component will
> stop causing all other PTC to be killed instantly regardless
> of their execution state.
>
> As a summary: your problem description needs some
> clarification or I have misunderstood something ;)
>
> Best regards,
>
>
>
> Gábor Ziegler M.Sc.E.E., dr.univ
> Test System Engineer
> Test Competence Center
>
> Ericsson Hungary Ltd.
>
> Research & Development
> Budapest, XI. Irinyi. J. u. 4-20.
> www.ericsson.com
>
> Office: +36 1 437 7361
> Fax: +36 1 439 5176
> Mobile: +30 30 219 9805
> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1.
> Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám:
> 01-09-070937
>
> This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data
> corruption, interception, unauthorized amendment, tampering
> and viruses, and we only send and receive emails on the basis
> that we are not liable for any such corruption, interception,
> amendment, tampering or viruses or any consequences thereof.
>
>
> >
> > function sync() runs on SyncComp {
> > p_sync.send (SyncRequest: {});
> > p_sync.receive (SyncResponse: {});
> > }
> > **************************************************
> >
> > function syncCompBehavior(integer n) runs on SyncComp {
> >
> > var SyncCompList listOfSenders;
> >
> > var integer i := 0;
> >
> > alt {
> >
> > [] p_sync.receive (
> >
> > SyncRequest: {}) -> sender listOfSenders {
> >
> > i := i + 1;
> >
> > if (i < n) {
> >
> > repeat;
> >
> > } else {
> >
> > for (i := 0; i < n; i := i + 1) {
> >
> > p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
> >
> > }
> >
> > i := 0;
> >
> > repeat;
> >
> > }
> >
> > }
> >
> > [] all component.done {};
> >
> > }
> >
> > }
> >
> > ..........................................................
> > Mit freundlichem Gruß / Kind regards
> > Alina Maria Luca
> > Siemens VDO Automotive
> > SV I IS RD AD IAS SW TA
> > B-dul Poitiers no. 10
> > 700671 Iasi
> > Romania
> > Tel. +40 (256) 30 - 7029
> > E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > <blocked::mailto:alina.luca@siemens.com>
> >
>

Hi Gabor and Alina.



I came to the same conclusion as Gabor. Here's some execution trace:



In your code you have



c_cmComp.start(f_HDD_MP3());

c_canComp.start (f_RunDown());

syncCompBehavior(2);

all component.done;



There is no guarantee which component gets to call synch() first,

despite that you started CM before CAN, as it is up to the scheduling

and that is outside the scope of TTCN-3. The order does not matter in this case

but worth to mention:



CM 1. synch() in and blocks

CAN 1. synch() in and blocks

MTC synchCompBehaviour()



or



CAN 1. synch() in and blocks

CM 1. synch() in and blocks

MTC synchCompBehaviour()





Now MTC has sent the sync response to both CM and CAN. Which one gets

executed first is not guaranteed by any means.



If CAN wakes up first, and the function RunDown() is such that is

is possibly can execute freely all the way to the last end two sync() calls,

then:



CAN 1. synch() returns

CAN all the commands until..

CAN 2. synch() in and blocks



CM 1. synch() returns

CM 2. synch() in and blocks



MTC synchCompBehaviour()



CAN 2. synch() returns

CAN 3. synch() in and blocks



CM 2. synch() returns

CM 3. synch() in and block



MTC synchCompBehaviour()



CAN 3. synch() returns

CAN done with f_RunDown



CM 3. synch() returns

CM 4. synch in -> blocked forever in f_HDD_MP3

// Antti Hyrkkänen @ Plenware
// www.plenware.fi/en <www.plenware.fi/en>

________________________________

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 Gábor Ziegler (IJ/ETH)
Sent: 17. elokuuta 2007 13:53
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running



Hi, Alina,



With your sync() implementation you can never execute "double" sync alone, since the first sync of the double-sync would block until the other component performs a sync and the second-sync of the double-sync would block until the other component performs again a sync.



That is, with your sync() implementation you cannot sync to yourself, only to some other component.



With your sync(), the number of sync() function calls must be equal in both components. If not, than the component with more sync() calls will be stuck forever eventually. In the example below, f_RunDown has 3 three calls to sync(), while f_HDD_MP3() has 5. That is, f_HDD_MP3() will be deadlocked in its (3+1)th sync() call forever, because its peer-component never performs its fourth sync (it has been "done" some times after its third sync())



BR,

Gabor










________________________________


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 Luca, Alina
Sent: 2007. augusztus 17. 12:41
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running

Yes, but on f_HDD_MP3() I have used double sync instruction

sync();

sync();



In order to block actual compenent and to run the other one only.



Is this correct?






________________________________


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 Gábor Ziegler (IJ/ETH)
Sent: Friday, August 17, 2007 1:30 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running

Hi Alina,



Inspect your code in parallel: f_RunDown has only 3 syncs, while f_HDD_MP3 has 5



function f_RunDown()runs on CANComp

{



//1st sync======
sync();

f_CanSetUp();

***send statement

canTGuard.start;

*** alt block

{

}

canP.send(CanMessageId(1397,'00000000'O));

canP.send(CanMessageId(707,'00'O));

canTGuard.start;

**** alt block

{

}

f_RunUp();

//2nd sync=====
sync();





//3rd sync======
sync();

}







function f_HDD_MP3() runs on cmComp{

********************** send/receive statements

//1st sync======
sync();

here is double sync:

sync();

sync();





















//2nd sync===
sync();

here is double sync:

sync();

sync();

********************** send/receive statements

//3rd sync=====
sync();

//4th sync =====
//would block forever
sync();

********************** send/receive statements

//5th sync=====
sync();

}





Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center
IJ/ETH

Ericsson Hungary Ltd.
Research & Development
ECN: 831 7361
Web: mwlx122.eth.ericsson.se:8081/~egbozie



>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 11:55
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> I will try to explain better.
>
> Test case is running on a component called testComponent.
> After that I created the next two compoenents:
>
> var cmComp c_cmComp := cmComp.create;
> var CANComp c_canComp := CANComp.create;
>
> connect (c_cmComp: p_sync, mtc: p_sync);
> connect (c_canComp: p_sync, mtc: p_sync);
>
> map (c_cmComp: InOutPort, system: InOutPort);
> map (c_canComp:canP, system:canP);
>
> after that we have the main flow:
>
> c_cmComp.start(f_HDD_MP3());
> c_canComp.start (f_RunDown());
> syncCompBehavior(2);
> all component.done;
>
>
> The functions sync () and syncCompBehavior() are described below.
>
> The f_RunDown() has the following content:
>
> function f_RunDown()runs on CANComp
> {
>
> sync();
> f_CanSetUp();
> ******************************************send statement
> canTGuard.start;
>
> ************ alt block
> {
>
> }
> canP.send(CanMessageId(1397,'00000000'O));
> canP.send(CanMessageId(707,'00'O));
> canTGuard.start;
>
> *********** alt block
> {
>
> }
>
> f_RunUp();
> sync();
> sync();
>
> }
>
>
> Now, f_HDD_MP3() looks like this:
>
> function f_HDD_MP3() runs on cmComp{
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
>
> }
>
>

---

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 Gábor
> Ziegler (IJ/ETH)
> Sent: Friday, August 17, 2007 12:39 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> Hi Alina,
>
> See comments inline
>
> >

---

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 Luca, Alina
> > Sent: 2007. augusztus 17. 10:51
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Parallel components running
> >
> >
> > Hello,
> >
> > I would like to share with you the following situation,
> > encountered while working with parallel components and to
> > kindly ask for your opinion on this.
> > I have the following flow in the test case, using two created
> > components, c_cmComp and c_canComp.
> > I have described below also the functions sync() and
> > syncCompBehavior().
> >
> > The problem appears inside the f_HDD_MP3() function, running
> > on c_cmComp. When performing sync() twice, I'm expecting for
> > the c_cmComp to stop and to run the behavior on c_canComp.
>
> You have not provided any information about what is inside of
> this f_HDD_MP3() behavior. If it indeed calls sync() twice
> that will cause the component (the MTC???) running the
> syncCompBehavior() in the first code block to leave the
> function's body. It has no effects on the execution state of
> c_canComp.
>
> > Unfortunately, this thing happens only when performing double
> > sync() for the first time. On the second try, the behavior
> > remains on the c_cmComp which calls twice sync. Is this
> > behavior normal?
> >
>
> Your problem description is under-defined, at least for me.
>
> I suppose that the first block of code is running on neither
> c_cmComp nor c_CanComp, since you have stated that both are
> "created". Possibly it is some "c_syncComp" of type SyncComp,
> or of a component type that extends SyncComp. I suppose that
> this is the MTC.
>
> > ********************************************
> > c_cmComp.start(f_HDD_MP3());
> >
> > c_canComp.start (f_RunDown());
> >
> > syncCompBehavior(2);
> >
> > **********************************************
> The semantics of the above code (supposing that "c_syncComp"
> is the component that executes)
> 1. c_syncComp instructs c_cmComp to run the behavior
> f_HDD_MP3. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_cmComp to actually start. Furthermore as soon as
> c_cmComp finishes the execution of f_HDD_MP3 it will die
> (unless you have created this as an "alive" component)
>
> 2. c_syncComp instructs c_canComp to run the behavior
> f_RunDown. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_canComp to actually start. Furthermore as soon as
> c_canComp finishes the execution of f_RunDown it will die
> (unless you have created this as an "alive" component)
>
> 3. Now at least three components are already running in
> parallel and independently from each other (without
> bothering with any "sync" operation of yours!) in your Test
> System: c_cmComp, c_canComp, c_syncComp
>
> 4. c_syncComp enters syncCompBehavior, with the actual
> argument of 2. Inside the function there is an alt statement,
> which is a blocking statement. It will leave the alt upon
> either of the conditions:
> 4.1 It has received SyncRequest from any component at least
> twice. The sender could be two different components or it
> could be the same component twice
> 4.2 All PTC except the MTC has been finished. If c_syncComp
> is not the MTC this condition will never be matched.
>
> If any of the conditions is met then execution will leave the
> syncCompBehavior. If this is the MTC and no further code is
> given to be executed to this MTC then this MTC component will
> stop causing all other PTC to be killed instantly regardless
> of their execution state.
>
> As a summary: your problem description needs some
> clarification or I have misunderstood something ;)
>
> Best regards,
>
>
>
> Gábor Ziegler M.Sc.E.E., dr.univ
> Test System Engineer
> Test Competence Center
>
> Ericsson Hungary Ltd.
>
> Research & Development
> Budapest, XI. Irinyi. J. u. 4-20.
> www.ericsson.com
>
> Office: +36 1 437 7361
> Fax: +36 1 439 5176
> Mobile: +30 30 219 9805
> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1.
> Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám:
> 01-09-070937
>
> This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data
> corruption, interception, unauthorized amendment, tampering
> and viruses, and we only send and receive emails on the basis
> that we are not liable for any such corruption, interception,
> amendment, tampering or viruses or any consequences thereof.
>
>
> >
> > function sync() runs on SyncComp {
> > p_sync.send (SyncRequest: {});
> > p_sync.receive (SyncResponse: {});
> > }
> > **************************************************
> >
> > function syncCompBehavior(integer n) runs on SyncComp {
> >
> > var SyncCompList listOfSenders;
> >
> > var integer i := 0;
> >
> > alt {
> >
> > [] p_sync.receive (
> >
> > SyncRequest: {}) -> sender listOfSenders {
> >
> > i := i + 1;
> >
> > if (i < n) {
> >
> > repeat;
> >
> > } else {
> >
> > for (i := 0; i < n; i := i + 1) {
> >
> > p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
> >
> > }
> >
> > i := 0;
> >
> > repeat;
> >
> > }
> >
> > }
> >
> > [] all component.done {};
> >
> > }
> >
> > }
> >
> > ..........................................................
> > Mit freundlichem Gruß / Kind regards
> > Alina Maria Luca
> > Siemens VDO Automotive
> > SV I IS RD AD IAS SW TA
> > B-dul Poitiers no. 10
> > 700671 Iasi
> > Romania
> > Tel. +40 (256) 30 - 7029
> > E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > <blocked::mailto:alina.luca@siemens.com>
> >
>

Hello,

I must say you're right.
Nevertheless, the main reason I'm calling sync() so many times in f_HDD_MP3() is that I need to execute f_RunDown() twice, during the f_HDD_MP3(), at different moments of time. First execution works fine, but, the second desn't start f_RunDown() on CAN at all. Maybe my approach is not the best. How can I execute twice this function?

Thank you very much,
Alina

________________________________

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 Hyrkkänen
Sent: Friday, August 17, 2007 1:59 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running



Hi Gabor and Alina.



I came to the same conclusion as Gabor. Here's some execution trace:



In your code you have



c_cmComp.start(f_HDD_MP3());

c_canComp.start (f_RunDown());

syncCompBehavior(2);

all component.done;



There is no guarantee which component gets to call synch() first,

despite that you started CM before CAN, as it is up to the scheduling

and that is outside the scope of TTCN-3. The order does not matter in this case

but worth to mention:



CM 1. synch() in and blocks

CAN 1. synch() in and blocks

MTC synchCompBehaviour()



or



CAN 1. synch() in and blocks

CM 1. synch() in and blocks

MTC synchCompBehaviour()





Now MTC has sent the sync response to both CM and CAN. Which one gets

executed first is not guaranteed by any means.



If CAN wakes up first, and the function RunDown() is such that is

is possibly can execute freely all the way to the last end two sync() calls,

then:



CAN 1. synch() returns

CAN all the commands until..

CAN 2. synch() in and blocks



CM 1. synch() returns

CM 2. synch() in and blocks



MTC synchCompBehaviour()



CAN 2. synch() returns

CAN 3. synch() in and blocks



CM 2. synch() returns

CM 3. synch() in and block



MTC synchCompBehaviour()



CAN 3. synch() returns

CAN done with f_RunDown



CM 3. synch() returns

CM 4. synch in -> blocked forever in f_HDD_MP3

// Antti Hyrkkänen @ Plenware
// www.plenware.fi/en <www.plenware.fi/en>

________________________________

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 Gábor Ziegler (IJ/ETH)
Sent: 17. elokuuta 2007 13:53
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running



Hi, Alina,



With your sync() implementation you can never execute "double" sync alone, since the first sync of the double-sync would block until the other component performs a sync and the second-sync of the double-sync would block until the other component performs again a sync.



That is, with your sync() implementation you cannot sync to yourself, only to some other component.



With your sync(), the number of sync() function calls must be equal in both components. If not, than the component with more sync() calls will be stuck forever eventually. In the example below, f_RunDown has 3 three calls to sync(), while f_HDD_MP3() has 5. That is, f_HDD_MP3() will be deadlocked in its (3+1)th sync() call forever, because its peer-component never performs its fourth sync (it has been "done" some times after its third sync())



BR,

Gabor










________________________________


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 Luca, Alina
Sent: 2007. augusztus 17. 12:41
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running

Yes, but on f_HDD_MP3() I have used double sync instruction

sync();

sync();



In order to block actual compenent and to run the other one only.



Is this correct?






________________________________


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 Gábor Ziegler (IJ/ETH)
Sent: Friday, August 17, 2007 1:30 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running

Hi Alina,



Inspect your code in parallel: f_RunDown has only 3 syncs, while f_HDD_MP3 has 5



function f_RunDown()runs on CANComp

{



//1st sync======
sync();

f_CanSetUp();

***send statement

canTGuard.start;

*** alt block

{

}

canP.send(CanMessageId(1397,'00000000'O));

canP.send(CanMessageId(707,'00'O));

canTGuard.start;

**** alt block

{

}

f_RunUp();

//2nd sync=====
sync();





//3rd sync======
sync();

}







function f_HDD_MP3() runs on cmComp{

********************** send/receive statements

//1st sync======
sync();

here is double sync:

sync();

sync();





















//2nd sync===
sync();

here is double sync:

sync();

sync();

********************** send/receive statements

//3rd sync=====
sync();

//4th sync =====
//would block forever
sync();

********************** send/receive statements

//5th sync=====
sync();

}





Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer
Test Competence Center
IJ/ETH

Ericsson Hungary Ltd.
Research & Development
ECN: 831 7361
Web: mwlx122.eth.ericsson.se:8081/~egbozie



>

---

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 Luca, Alina
> Sent: 2007. augusztus 17. 11:55
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> I will try to explain better.
>
> Test case is running on a component called testComponent.
> After that I created the next two compoenents:
>
> var cmComp c_cmComp := cmComp.create;
> var CANComp c_canComp := CANComp.create;
>
> connect (c_cmComp: p_sync, mtc: p_sync);
> connect (c_canComp: p_sync, mtc: p_sync);
>
> map (c_cmComp: InOutPort, system: InOutPort);
> map (c_canComp:canP, system:canP);
>
> after that we have the main flow:
>
> c_cmComp.start(f_HDD_MP3());
> c_canComp.start (f_RunDown());
> syncCompBehavior(2);
> all component.done;
>
>
> The functions sync () and syncCompBehavior() are described below.
>
> The f_RunDown() has the following content:
>
> function f_RunDown()runs on CANComp
> {
>
> sync();
> f_CanSetUp();
> ******************************************send statement
> canTGuard.start;
>
> ************ alt block
> {
>
> }
> canP.send(CanMessageId(1397,'00000000'O));
> canP.send(CanMessageId(707,'00'O));
> canTGuard.start;
>
> *********** alt block
> {
>
> }
>
> f_RunUp();
> sync();
> sync();
>
> }
>
>
> Now, f_HDD_MP3() looks like this:
>
> function f_HDD_MP3() runs on cmComp{
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
> sync();
>
> ********************** send/receive statements
>
> sync();
>
> }
>
>

---

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 Gábor
> Ziegler (IJ/ETH)
> Sent: Friday, August 17, 2007 12:39 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Parallel components running
>
> Hi Alina,
>
> See comments inline
>
> >

---

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 Luca, Alina
> > Sent: 2007. augusztus 17. 10:51
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Parallel components running
> >
> >
> > Hello,
> >
> > I would like to share with you the following situation,
> > encountered while working with parallel components and to
> > kindly ask for your opinion on this.
> > I have the following flow in the test case, using two created
> > components, c_cmComp and c_canComp.
> > I have described below also the functions sync() and
> > syncCompBehavior().
> >
> > The problem appears inside the f_HDD_MP3() function, running
> > on c_cmComp. When performing sync() twice, I'm expecting for
> > the c_cmComp to stop and to run the behavior on c_canComp.
>
> You have not provided any information about what is inside of
> this f_HDD_MP3() behavior. If it indeed calls sync() twice
> that will cause the component (the MTC???) running the
> syncCompBehavior() in the first code block to leave the
> function's body. It has no effects on the execution state of
> c_canComp.
>
> > Unfortunately, this thing happens only when performing double
> > sync() for the first time. On the second try, the behavior
> > remains on the c_cmComp which calls twice sync. Is this
> > behavior normal?
> >
>
> Your problem description is under-defined, at least for me.
>
> I suppose that the first block of code is running on neither
> c_cmComp nor c_CanComp, since you have stated that both are
> "created". Possibly it is some "c_syncComp" of type SyncComp,
> or of a component type that extends SyncComp. I suppose that
> this is the MTC.
>
> > ********************************************
> > c_cmComp.start(f_HDD_MP3());
> >
> > c_canComp.start (f_RunDown());
> >
> > syncCompBehavior(2);
> >
> > **********************************************
> The semantics of the above code (supposing that "c_syncComp"
> is the component that executes)
> 1. c_syncComp instructs c_cmComp to run the behavior
> f_HDD_MP3. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_cmComp to actually start. Furthermore as soon as
> c_cmComp finishes the execution of f_HDD_MP3 it will die
> (unless you have created this as an "alive" component)
>
> 2. c_syncComp instructs c_canComp to run the behavior
> f_RunDown. This is a non-blocking statement for "c_syncComp",
> that is, its execution immediately continues, without waiting
> for c_canComp to actually start. Furthermore as soon as
> c_canComp finishes the execution of f_RunDown it will die
> (unless you have created this as an "alive" component)
>
> 3. Now at least three components are already running in
> parallel and independently from each other (without
> bothering with any "sync" operation of yours!) in your Test
> System: c_cmComp, c_canComp, c_syncComp
>
> 4. c_syncComp enters syncCompBehavior, with the actual
> argument of 2. Inside the function there is an alt statement,
> which is a blocking statement. It will leave the alt upon
> either of the conditions:
> 4.1 It has received SyncRequest from any component at least
> twice. The sender could be two different components or it
> could be the same component twice
> 4.2 All PTC except the MTC has been finished. If c_syncComp
> is not the MTC this condition will never be matched.
>
> If any of the conditions is met then execution will leave the
> syncCompBehavior. If this is the MTC and no further code is
> given to be executed to this MTC then this MTC component will
> stop causing all other PTC to be killed instantly regardless
> of their execution state.
>
> As a summary: your problem description needs some
> clarification or I have misunderstood something ;)
>
> Best regards,
>
>
>
> Gábor Ziegler M.Sc.E.E., dr.univ
> Test System Engineer
> Test Competence Center
>
> Ericsson Hungary Ltd.
>
> Research & Development
> Budapest, XI. Irinyi. J. u. 4-20.
> www.ericsson.com
>
> Office: +36 1 437 7361
> Fax: +36 1 439 5176
> Mobile: +30 30 219 9805
> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Ericsson Magyarország Kft., Székhely: Budapest, Laborc u.1.
> Nyilvántartó cégbíróság: Fővárosi Bíróság. Cégjegyzékszám:
> 01-09-070937
>
> This communication is confidential and intended solely for
> the addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has
> been sent to you in error, please notify the sender by
> replying to this transmission and delete the message without
> disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data
> corruption, interception, unauthorized amendment, tampering
> and viruses, and we only send and receive emails on the basis
> that we are not liable for any such corruption, interception,
> amendment, tampering or viruses or any consequences thereof.
>
>
> >
> > function sync() runs on SyncComp {
> > p_sync.send (SyncRequest: {});
> > p_sync.receive (SyncResponse: {});
> > }
> > **************************************************
> >
> > function syncCompBehavior(integer n) runs on SyncComp {
> >
> > var SyncCompList listOfSenders;
> >
> > var integer i := 0;
> >
> > alt {
> >
> > [] p_sync.receive (
> >
> > SyncRequest: {}) -> sender listOfSenders {
> >
> > i := i + 1;
> >
> > if (i < n) {
> >
> > repeat;
> >
> > } else {
> >
> > for (i := 0; i < n; i := i + 1) {
> >
> > p_sync.send (SyncResponse: {}) to valueof(listOfSenders);
> >
> > }
> >
> > i := 0;
> >
> > repeat;
> >
> > }
> >
> > }
> >
> > [] all component.done {};
> >
> > }
> >
> > }
> >
> > ..........................................................
> > Mit freundlichem Gruß / Kind regards
> > Alina Maria Luca
> > Siemens VDO Automotive
> > SV I IS RD AD IAS SW TA
> > B-dul Poitiers no. 10
> > 700671 Iasi
> > Romania
> > Tel. +40 (256) 30 - 7029
> > E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > <blocked::mailto:alina.luca@siemens.com>
> >
>

I'm not completely sure what works in your situation, but one solution

is to define a new component type that is a combination of

the CM and CAM component types, and then run f_HDD_MP3() in it, and

call the f_RunDown() directly from f_HDD_MP3() when needed.



If the CAM component represent some bigger entity that is meant to

perform some other tasks in addition to RunDown, and you want to keep

the component types separated, then you could define an interface

between the CAM and the CM components. CM and maybe other components

could ask the CAM component to perform these different tasks. For example

when CM thinks that RunDown should be performed, CM could send the CAM

component a message "Please execute RunDown", and after CAM has done

that, CAM would tell the CM in some acknowledgement message that

"RunDown executed ok". The CAM component would just sit there in an

alt statement and wait for new instructions from other components if it does not

have anything to do.



Antti



// Antti Hyrkkänen @ Plenware
// www.plenware.fi/en <www.plenware.fi/en>

________________________________

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 Luca, Alina
Sent: 17. elokuuta 2007 14:39
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Parallel components running



Hello,



I must say you're right.

Nevertheless, the main reason I'm calling sync() so many times in f_HDD_MP3() is that I need to execute f_RunDown() twice, during the f_HDD_MP3(), at different moments of time. First execution works fine, but, the second desn't start f_RunDown() on CAN at all. Maybe my approach is not the best. How can I execute twice this function?



Thank you very much,

Alina