Re: New draft LRM available, including TLM-1

Philipp,

Yes, I agree on all points.

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
Stuart Swan <stuart@cadence.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
12/09/2010 01:06
Subject:
Re: New draft LRM available, including TLM-1

John,

Regarding rendezvous semantics of 0-sized tlm_fifos, I can see that this
is useful. OTOH, it might be quite difficult to find a
consistent wording for the interface semantics without always
special-casing this case.

Regarding the destructor, I'm in line with Stuart. In fact, I don't
understand what you mean by "the fifo only stores references".

  Since TLM-1 is meant to implement message-passing semantics, the FIFO
has no choice but to copy the transaction objects to its local buffer
according to the limited lifetime guarantees given in 18.1.6 (g).

  If the FIFO stores (and owns) _copies_ of the transaction objects
internally, I think these objects have to be destroyed by the FIFO
itself. (Of course, if the FIFO stores pointers, their pointees should
be left as they are).

  Additionally, there's another issue related to the lifetime of
transaction objects stored inside (tlm_)fifos:

  A transaction object, that has been removed via get() from the fifo
should be destroyed or reset explicitly immediately after the get()
call. Otherwise, objects are not properly released until their old
place is overwritten again, which can cause problems with reference
counted objects (e.g. shared_ptr, or CoW objects).

  Last, but not least, the wording for the member function nb_peek (both
in 18.2.3 and 18.2.5) states, that it "shall return a reference to the
item at a given position". Strictly speaking, a true reference would
imply that changes to this element in the fifo (e.g. via nb_poke) would
be reflected in the previously returned value as well. Maybe the
following would be more accurate:

"Member function nb_peek shall assign the item at a given
 position in the fifo to the reference argument. Position 0..."

Thanks,
  Philipp

On 10/09/10 16:02, 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

[attachment "signature.asc" deleted by John Aynsley/doulos]

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