Re: TLM issues

John, Stuart,

let me explain the issue at hand a bit more detailed.

Firstly, please consider a transaction object with a copy-on-write
implementation, i.e. the payload is shared between multiple copies as
long as they are not modified. Many expensive copies of the payload can
potentially be saved this way.

struct cow_payload; // some payload class with copy-on-write

cow_payload gen_payload()
{
  // create an expensive payload
  // ownership is taken by the payload object
  return cow_payload( new std::vector<unsigned char>( 1024 ) );
}
// on exit, the local temporary is destroyed
// newly returned payload has exclusive ownership

tlm_fifo< cow_payload > fifo;
  // internally: array of cow_payloads

{
   cow_payload p = gen_payload();
   sc_assert( p.is_exclusive() );
   fifo.write( p );
   sc_assert( ! p.is_exclusive() );
}
// payload object inside FIFO now has exclusive
// ownership, since p is destroyed

// --- crucial point is here! ---
{
  cow_payload p = fifo.read();
  sc_assert( p.is_exclusive() );
}

  What I want the interfaces to guarantee is, that no channel should
keep "copies" of the transaction objects around, that are not needed any
more. At least for a FIFO, the "unused" places in the buffer are
logically empty and should not hold any references to "old" objects.

  The transaction objects should logically "flow" through the channel.
When they are consumed (and the semantics do not foresee subsequent
access), the internally held copies should end their lifetime.

So I think, the current wording does not yet cover this issue.
Opinions?

Greetings from Oldenburg,
  Philipp

On 12/01/11 14:14, john.aynsley@doulos.com wrote:
> Philipp, Stuart,
>
> Agreed. I have added new points as follows:
>
> 18.1.6 h) The recipient of a transaction may take a copy of the
> transaction object for subsequent processing, in which case the
> application shall be responsible for ensuring that the copy is destroyed
> when it is no longer needed.
>
>
> 18.1.7 e) The application shall provide a destructor for any transaction
> class that has non-trivial destruction semantics (such as a transaction
> with non-trivial deep copy semantics). The application shall be
> responsible for ensuring that each transaction object is destroyed when it
> is no longer required.
>
>
> Is that sufficient?
>
> 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:
> 11/01/2011 19:23
> Subject:
> RE: TLM issues
>
>
>
> John, All-
> A comment below.
> -Stuart
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Tuesday, January 11, 2011 5:22 AM
> To: systemc-p1666-technical@eda.org
> Subject: TLM issues
>
>
>
> 18.1 TLM-1 message passing interfaces
>
> If objects with non-trivial destructors are passed through the TLM-1
> message passing interfaces, it is important that internal copies are
> properly destroyed when they are no longer "needed".
>
> Consider the case of a tlm_fifo< shared_ptr<foo> >. It is important,
> that the internal copies in the FIFO are correctly released, after they
> have been taken from the FIFO. This is not explicitly mentioned in the
> description of the interfaces (or in the lifetime section FWIW). This is
> also a bug in the tlm_fifo reference implementation currently.
>
> Opinions?
> [Stuart] I agree. We should at least recommend that models that use the
> TLM 1.0 interfaces properly use dtors for transaction objects.
>
>
>
>
>
>

-- 
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 · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.