RE: Identifying quickly what is the current process

Philip, All

Some comments below.

Thanks
Stuart

>-----Original Message-----
>From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>Sent: Friday, March 12, 2010 10:46 AM
>To: Stuart Swan
>Cc: john.aynsley@doulos.com; Eric PAIRE; Jerome CORNET; 'Laurent MAILLET-CONTOZ'; systemc-p1666-
>technical@eda.org
>Subject: Re: Identifying quickly what is the current process
>
>On 12/03/10 19:25, Stuart Swan wrote:
>> I also like the idea of adding sc_process_handle::operator< also, but I'm not quite
>> sure how it would be defined. Would the comparison be based on the full process name,
>> if the process handle is valid ?
>
> Since the referenced process object stays valid as long as the last
>referencing handle lives on (even after termination of the process), it
>would be good enough to just use the plain process pointer inside.
>
> This is actually the benefit of the explicit handle over using the raw
>pointer e.g. as a key in a map: The referenced process object could get
>deleted if the process terminates and no handle is still referencing it.
>
> Two invalid handles (with internal pointers being NULL) are then
>considered equivalent (a<b == false && b<a == false), which is OK for
>the total ordering, I think.

But isn't there a problem that the ordering between two processes then
changes between the time when the processes are alive and then one or
both terminates ? For sorting within maps etc the ordering needs to remain
constant , right ?

>
>So the implementation could simply look like (based on the OSCI
>implementation):
>
>inline bool operator < (
> const sc_process_handle& left, const sc_process_handle& right )
> { return left.m_target_p < right.m_target_p; }
>
> Strictly speaking, this is not guaranteed to work by the C++ standard.
> For a total ordering over arbitrary pointers (not from within the same
>object/array), you should use std::less. But this is minor issue for
>the usual platforms.
>

But this is not portable (ie won't necessarily give same result) across
different platforms or simulators. Would be nice if we could make it portable..

>Greetings from Oldenburg,
>Philipp
>
>[snip]
>
>--
>Philipp A. Hartmann
>Hardware/Software Design Methodology Group
>
>OFFIS
>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.