RE: [sv-ec] 9.4.2 example

 
exactly  -  I wanted those 2 lines to be changed as below
 
DANiel

  _____  

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Arturo Salz
Sent: 27 maja 2009 19:24
To: Rich, Dave; Bresticker, Shalom
Cc: sv-ec@eda.org
Subject: RE: [sv-ec] 9.4.2 example



Daniel's proposal is correct. We should change the example as he suggests -
however, his change involves not just one but two lines (the ones
highlighted in blue):

 

Packet p = new; // Packet 1

Packet q = new; // Packet 2

initial fork

   @(p.status);   // Wait for status in Packet 1 to change

   @ p;           // Wait for a change to handle p

   # 10 p = q;    // triggers @p.

   // @(p.status) now waits for status in Packet 2 to change,

   // if not already different from Packet 1

join

 

            Arturo

 

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich,
Dave
Sent: Wednesday, May 27, 2009 8:38 AM
To: Bresticker, Shalom
Cc: sv-ec@eda.org
Subject: RE: [sv-ec] 9.4.2 example

 

Oh, you're right, the p's and q's are reversed on that line and the one
above in the LRM. The example below is what you want to change it to.

 

  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Wednesday, May 27, 2009 8:03 AM
To: Rich, Dave
Cc: sv-ec@server.eda.org
Subject: RE: [sv-ec] 9.4.2 example

 

#10 p=q ;

 

is the line that Daniel suggests to add to the LRM. It is not there now.

 

Shalom

 

  _____  

From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Wednesday, May 27, 2009 6:00 PM
To: Bresticker, Shalom; sv-ec@server.eda.org
Subject: RE: [sv-ec] 9.4.2 example

 

 

  _____  

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Wednesday, May 27, 2009 6:19 AM
To: sv-ec@server.eda.org
Subject: [sv-ec] 9.4.2 example

 

Hi,

 

Daniel Mlynek wrote in http://www.eda-stds.org/sv-ec/hm/6589.html:

 

Anyway the main problem is that I think the example in 9.4.2 Event control
is wrong. 

Comments says:  "// @(p.status) now waits for status in Packet 2 to change,
if not already different from Packet 1"  

but p is not changed in the example at all. 

[DR] #10 p=q; is the change to p. q is pointing to pPacket 2

If it would be assigned with handle pointing on object "Packet 1" then
example would be ok. 

My proposal is to change :

 

Packet p = new; // Packet 1

Packet q = new; // Packet 2

initial fork

        @(p.status); // Wait for status in Packet 1 to change

        @p;          // Wait for a change to handle p

        #10 p = q;  // triggers @p. 

        // @(p.status) now waits for status in Packet 2 to change,

        // if not already different from Packet 1

join

 

I think Daniel is correct, that the comment looks wrong.

 

Editorially, this example seems to be referring to the definition of Packet
in 8.2. 

Otherwise, who knows what "status" is?

If so, the text should refer the reader to 8.2.

 

Thanks,

Shalom

 

Shalom Bresticker

Intel LAD DA

Jerusalem, Israel

+972  2 589 6582 (office)

+972 54 721 1033 (cell)

 

 

---------------------------------------------------------------------
Intel Israel (74) Limited
 
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

---------------------------------------------------------------------
Intel Israel (74) Limited
 
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.