Re: Rendezvous semantics for tlm_fifo

John,

my vote would be A) for the reasons you already gave.

IMHO, implementing (and finding a consistent wording for) it in the
standard is quite difficult and may not be worth the effort.

Thanks,
  Philipp

On 22/09/10 07:54, john.aynsley@doulos.com wrote:
> 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.
>
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.