Re: TLM issues

John,

I like your proposal.

Having the general rules in 18.1.6/7 is fine in combination with the
explicit specification of tlm_fifo's behaviour in that regard.

  Since tlm_fifo is the only TLM-1 channel provided by the
implementation, it's sufficient to add this specific rule to tlm_fifo
directly and restrict other channels/targets via the application
requirements.

Thanks,
  Philipp

On 12/01/11 17:08, john.aynsley@doulos.com wrote:
> Philipp,
>
> I think I understand your issue. The proposed 18.1.6 h) says "the
> application shall be responsible for ensuring that the copy is destroyed
> when it is no longer needed". Of course, the difficulty is with "no longer
> needed", but I do not see a better way to formulate such a general
> catch-all rule.
>
> How about we add something like the following to 18.3.1. specifically for
> tlm_fifo:
>
> When transaction objects are retrieved from the fifo using calls to get or
> nb_get, the fifo shall not retain any internal copy of or reference to the
> retrieved transaction objects.
>
> Cheers,
>
> 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/01/2011 14:26
> Subject:
> 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.