Re: Proposal for sc_process_handle

All,

I propose we add the operator< and method swap to sc_process_handle with
the definitions proposed by Philipp. We believe this will address Jerome's
original enhancement request for the ability to have a unique process
identifier such that processes can be catalogued in a C++ container.

(There are two obvious implementations: either never re-use process
objects as per the current OSCI implementation, or base operator< on some
new internal unique process id.)

Please "vote" with AGREE or DISAGREE (with a good reason and a solid
counter-proposal!)

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
23/03/2010 09:30
Subject:
Re: Proposal for sc_process_handle

John,

now I see your point. It's a corner case, but a valid one, I think.
In this scenario, the inconsistency you describe could happen in
invalidating implementations.

  Apart from your suggestion to use a unique id internally in such
implementations, we could also forbid handle invalidation on process
termination altogether. Are there any invalidating implementations out
there? The reference implementation and quite likely the ones based on
it are keeping the process objects after termination. So if we don't
break existing implementations (or get no objections from their vendors
on this change), this might be the easiest way to go.

  If we want to keep the invalidation possibility, the tricky part is to
get the wording right for the standard. Your example of zombie
reincarnations should of course be covered.

If I'm not missing anything, the following criteria should be met:

- valid and equal handles are equivalent, if and only if they are equal:
  if ( a.valid() && b.valid() )
    sc_assert( a==b && !(a < b) && !(b < a)
             || a!=b && ( (a < b) || (b < a) );

- a valid and an invalid handle are never equivalent (your example)
  if( a.valid() && !b.valid() )
    sc_assert( (a < b) || (b < a) );

- two invalid handles are equivalent, if and only if they formerly
  pointed to the same process object (or no process at all), e.g.
  a = b = sc_get_current_process_handle();
  wait( a.terminated_event() );
  sc_assert( !(a < b) && !(b < a) );
  // implementation dependent:
  sc_assert( a.valid() && a==b || !a.valid() && a!=b );

How an implementation guarantees this behaviour, should not be part of
the standard. But your proposal to use a unique id internally should be
fine.

Greetings from Oldenburg,
Philipp

On 22/03/10 12:33, john.aynsley@doulos.com wrote:
>
> I agree with your analysis so far, but the problem I am imagining starts

> right there...
>
> Suppose we have 2 handles to the same dead process:
>
> a.valid == false
> b.valid == false
> (a == b) == false
> !(a < b) && !(b < a)
>
> We then create a new process and a handle to it
>
> c.valid = true
> (c == a) == false
> (c == b) == false
>
> Unfortunately, the new process object just happens to have the same
> address as the dead process (a reincarnated zombie)
>
> !(b < c) && !(c < b)
> !(c < a) && !(a < c)
>
> So, assuming our std::map still contains handle a, the new handle c
cannot
> be inserted into the map because it falls into the same equivalence
> partition as a and b. As long as the map cataloguing our processes
> includes an (invalid) handle to the dead process, it cannot include any
> handle to the new process (the reincarnated zombie). If we were to clean

> out all the invalid handles from the map, we could then insert a new
valid
> handle to the process. On the other hand, if process objects never get
> deleted, so their storage never gets re-used, the problem does not
arise.
>
> I suppose the fix is to add a unique id (say 64 bits) to the process
> object that does not get recycled within a single simulation run, and
base
> equivalence on that.
>

[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.