Re: Proposal for sc_process_handle (was: Re: Identifying quickly what is the current process)

Whoops. If a dead process object gets reincarnated as another process with
another handle, haven't we got a problem? The new process would have
equivalent ordering to the dead process, no?

John A

From:
john.aynsley@doulos.com
To:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
Cc:
Bishnupriya Bhattacharya <bpriya@cadence.com>, Eric PAIRE
<eric.paire@st.com>, Jerome CORNET <jerome.cornet@st.com>, "'Laurent
MAILLET-CONTOZ'" <laurent.maillet-contoz@st.com>, Stuart Swan
<stuart@cadence.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
18/03/2010 11:09
Subject:
Re: Proposal for sc_process_handle (was: Re: Identifying quickly what is
the current process)
Sent by:
owner-systemc-p1666-technical@eda.org

Philipp,

Agreed. Cool. Swap too.

I would probably want to spell out "strict weak ordering" and "collation
order" rather than relying on familiarity with the C++ standard.

Just to be concrete, the following implementation...

  bool operator< (const sc_process_handle& r) const {
    return this->get_process_object() < r.get_process_object();
  }

would work fine, provided the implementation left the dangling pointers
unchanged following invalidation, right? (But I agree that the
implementation should be free to implement "strick weak ordering" however
it likes, and I agree the order could vary from run-to-run.)

Cheers,

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
Stuart Swan <stuart@cadence.com>, Bishnupriya Bhattacharya
<bpriya@cadence.com>, Eric PAIRE <eric.paire@st.com>, Jerome CORNET
<jerome.cornet@st.com>, 'Laurent MAILLET-CONTOZ'
<laurent.maillet-contoz@st.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
17/03/2010 17:28
Subject:
Proposal for sc_process_handle (was: Re: Identifying quickly what is the
current process)

John, all,

since you asked for more solid proposals regarding the operator< issue
on the sc_process_handle, I tried to put up a possible wording.

 Additionally, I would like to see the addition of a "swap" function,
which is widely used in modern C++ designs. Especially if the handle is
not guaranteed to be a small wrapper around the process pointer (and may
get invalidated upon process termination, etc.), this could be beneficial.

Please note, that my current proposal does _not_ require a reproducible
ordering. Comments on that are below.

On 15/03/10 17:38, Stuart Swan wrote:

> Also - if possible I'd like operator< to work reproducibly the same
> way on different implementations and platforms.

Sure, this _would_ be possible, but seems too costly, IMHO. I fail to
see any use case for this, anyhow. Stuart, in which scenario do you
envision a need for this deterministic ordering?

 Moreover, even process names are currently not strictly reproducible
across implementations (since elaboration order is not strictly defined
and thus automatically generated names may differ). So there may be
more changes needed to actually guarantee this.

 Without specifying the exact ordering, this operator can easily be
implemented in constant time, which is a Good Thing, I think.

> Since operator< will be called quite rarely, I think just using the
> full hierarchical name of the process is sufficient.

Why is it called rarely?

> On first call, we copy the name from the process object to the
> handle, so that if the process terminates then subsequent calls to
> operator< still work and return the same result.

 This would increase the cost of using handles quite significantly.
AFAIU, handles are meant to be light-weight and cheaply copyable.

 IMHO, it should be up to the implementation, how to keep the ordering
valid after the underlying process has terminated. For an invalidating
implementation, a simple boolean flag for the validity would be enough,
too. Then you can still use the (now potentially dangling) process
pointer for the operator< implementation.

If we do not define the exact ordering, something like the following
additions to section 5.6 could be sufficient:

----
[5.6.2 Class definition]
Add the following lines to the class definition:
 void swap( sc_process_handle& );
 bool operator< ( const sc_process_handle& ) const;
[5.6.5 Member functions]
Add the following paragraphs to the member function descriptions:
bool operator< ( const sc_process_handle & rhs ) const;
 The less-than operator shall return true, if and only if *this
 precedes rhs in the implementation's collation order.  The ordering
 of process handles shall define a strict weak ordering on the
 underlying process instances.
   The implementation is obliged to keep the relative ordering of a
 handle unchanged, even if it gets invalidated after the termination
 of the underlying process instance (see function terminated).
 NOTE -- The exact collation order is implementation-defined and may
         differ from run to run.
void swap( sc_process_handle& );
 The swap function shall swap the underlying process instances
 of two handles.
----
Remarks:
- The wording for operator< makes use of the "strict weak ordering"
  terminology from the C++ standard (25.3/p4).  Maybe we need to
  add a reference here.
- Should we add an example to the swap function description?
  Something like:
  sc_process_handle a, b = sc_get_current_process_handle();
  sc_assert( ! a.valid() );
  a.swap( b );
  sc_assert( a == sc_get_current_process_handle() && !b.valid() );
What do you think?
Philipp
-- 
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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.