Re: Proposal for sc_process_handle - AGREE

I agree. I think this clears up issues that were not resolved in the
original LRM.

Dave

-- 
Dr David Long 
Senior Consultant 
Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel:  + 44 (0)1425 471223                       Email: 
david.long@doulos.com 
Fax:  +44 (0)1425 471573                        http://www.doulos.com
--------------------------------------------------------------------------------
 This message may contain personal views which are not the views of
Doulos, unless specifically stated.
From:
john.aynsley@doulos.com
To:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, 
"Philipp A. Hartmann" <philipp.hartmann@offis.de>, jerome.cornet@st.com
Date:
23/03/2010 11:35
Subject:
Re: Proposal for sc_process_handle
Sent by:
owner-systemc-p1666-technical@eda.org
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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.