RE: Proposal for sc_process_handle: AGREE

John, All,

I have carefully read the email thread on this topic.

In summary, I agree with Philip's proposal. This is a nice addition to the sc_process_handle class. Thanks for hammering it out.

Some comments:

 *
To answer Philip's question, there are implementations that invalidate the process object ptr after the process terminates. The Cadence implementation is such - where it differs from OSCI.
 *
For such implementations, the issue of a reincarnated zombie (a new process object that has the same address as an old dead one) is a real issue. I'm glad that this was caught by John and already discussed
 *
I agree that using an unique integer id for each process object will allow an invalidating implementation to implement operator < correctly, as laid down below in Philip's 3 bullet points. Note that the corner case of two invalid handles where the handles never did point to any process objects need also be covered, and such handles should not be equivalent, and should not be equal (i.e. they should be unequal)
  sc_process_handle a,b;
  sc_assert(!(a<b) && !(b<a));
  sc_assert(a!=b);
This behavior is not implementation dependent and should be LRM-mandated.
(I believe this is covered in Philip's third bullet point below?)
An implementation would need to use a famous id (like 0) inside a process handle indicating non-process-object-association status, and the unique id of a process object always has to be different from this famous id. But that is implementation detail anyway.
 *
The wording of all this has to be carefully laid down in the LRM.

Thanks,
-Bishnupriya

________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, March 23, 2010 5:04 PM
To: systemc-p1666-technical@eda.org; Philipp A. Hartmann; jerome.cornet@st.com
Subject: 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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.