RE: TLM issues

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.

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