Rendezvous semantics for tlm_fifo

All,

We need to close this issue of the semantics of a zero-length tlm_fifo. There are two options on the table:

A) Make the behavior implementation-defined. This means no change to the current code, but a statement in the LRM that users should not rely on the current (rather useless) behavior

B) Change the LRM and the implementation to use rendezvous semantics, i.e. both writer and read may block and wait for one another.

Please vote A) or B).  If you don't care, it would probably be best to vote A), because it will take us a little more time and effort to implement B).

Thanks

John A
 

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: john.aynsley@doulos.com
From: Jerome CORNET <jerome.cornet@st.com>
Date: 09/14/2010 12:13PM
Cc: Stuart Swan <stuart@cadence.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: New draft LRM available, including TLM-1

                 John, All,
     
     no problem on our side regarding "switching" to rendezvous semantics.
     
     Jerome
     
     On 9/10/2010 4:02 PM, john.aynsley@doulos.com wrote: Stuart, All,
       
       Re. the tlm_fifo of size 0, I agree that the present semantics are fairly useless and that rendezvous semantics would be better. On the other hand, does anyone care?  What do other people think?
       
       Re. the tlm_fifo destructor, since the fifo only stores references to transaction objects whose lifetimes are managed elsewhere, I think it would be very odd if the tlm_fifo destructor interfered with the transaction objects themselves. Just my two cents.
       
       John A
       
       
                                         From: Stuart Swan <stuart@cadence.com> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org> Date: 09/09/2010 00:32 Subject: RE: New draft LRM available, including TLM-1
              
       
       
       John- I’ve read thru your new chapter 18 pretty carefully and it looks very good.
       I only found a few things, listed below.
        
       Thanks
       Stuart
        
       ***
        
       18.1.1 Description
        
       "TLM-1 message-passing, which equates to transaction-passing, is unidirectional."
       (Add?: The TLM-1 transport interface can be considered to be composed of two unidirectional
       channels which pass separate messages in each direction.)
        
       "In the case of method transport"
       <transport needs to be BOLD>
        
        
       18.3.4 Constructors and destructor
        
       "A bounded fifo may become full, an unbounded fifo cannot become full, and a fifo with size
       equal to 0 is both full and empty at the same time such that put and get would each block indefinitely."
       <stuart comment: I suppose the description for size 0 is accurate given how tlm_fifo is coded,
       but this has always seemed to me to be a bug in tlm_fifo. Maybe it is too late now but I've always thought
       that size 0 should imply rendezvous semantics thru tlm_fifo>
        
        
       virtual ~tlm_fifo();
       The destructor shall delete the first-in-first-out buffer but shall not delete any transaction objects
       held in the fifo.
       <stuart comment: isn't the latter part a bug? ie shouldn't the objects' dtor be called? >
        
        
       From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
             Sent: Thursday, September 02, 2010 2:42 AM
             To: systemc-p1666-technical@eda.org
             Subject: New draft LRM available, including TLM-1
        
       Folks,
         
           We've made available a new draft LRM that includes the TLM-1 Message Passing Interface (chapter 18).
         
           http://www.eda.org/twiki/pub/P1666/WebHome/1666-2005_Sept_01_10_with_labels.pdf
         
           Please review.
         
           John A
         
           
           --
           This message has been scanned for viruses and
           dangerous content by 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.
          
   

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