Re: Proposal for sc_process_handle: AGREE

Bishnupriya, Philipp,
 
Ignore anything I said about all invalid handles being in the same equivalence partition. Sorry, I was not thinking about stability.
 
It seems to me that the one key rule is:
 
* Two initialized handles are equivalent iff each handle currently (if still valid) or previously (if invalid) is associated with the same process instance as the other handle, and neither is equivalent to any uninitialized handle.
 
In this rule, either, one, or both handles may be invalid, and nothing is said about the equivalence of two uninitialized handles.
 
Further to that, there is a piece of advice:
 
* If you assign a handle that is stored in a map, you had better update the map following the assignment, or it will be stale.
 
If you store two uninitialized process handles in a map, I cannot see a reason why they should be equivalent or not equivalent, provided neither is equivalent to any initialized handle, and provided their order is stable. We should have a rule rather than it being implementation-defined, but I don't see that it matters which rule we chose, does it? I suppose it would affect the size of the map if there were a lot of uninitialized handles.
 
Regarding the timing of handle invalidation following process termination, given that it is implementation-defined in 1666-2005 (presumably to give implementors scope for optimization), I see no reason to start imposing constraints on invalidation now. But I don't really care if there is a compelling reason.
 
Thanks,
 
John A
 
 
-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----

To: Bishnupriya Bhattacharya <bpriya@cadence.com>
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 05/18/2010 03:11PM
Cc: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: Proposal for sc_process_handle: AGREE

Bishnupriya, John,

  since handles are more or less extended pointers, their behaviour can
be best compared to raw pointers with value semantics. In that sense,
it is correct: handle instances change whenever they are re-assigned (or
swap()'ed).

  The key issue is, that they (at least regarding their ordering) do not
magically change "from the outside".

  The map stores the key values internally as a (const) copy. As a
result, changes to the probe objects do not affect the internal keys in
the map. But changing the ordering depending on the validity would:

sc_process_handle p,q; // empty handles
std::map< sc_process_handle, int > m; // some map

// put a value for an empty handle in the map
m[p] = 1;

// empty handles are equivalent, "both" mapped values equal 1:
sc_assert( m[p] * m[q] == 1 );

// re-assign p to point to a different process
p = sc_spawn(...);

// new handle not in map
sc_assert( m.find( p ) == m.end() );

// store another value for this process in the map
m[p] = 2;

// now we have two key/value pairs in the map
sc_assert( m.size() == 2 );

// wait for termination
wait( p.terminated_event() );

// now, we still want to have (independently of the invalidation):

sc_assert( m.size() == 2 );
sc_assert( m[p] == 2 ); // (*) "maybe invalidated" handle can be found
sc_assert( m[q] == 1 ); // (**) empty handle as well

  If all invalid handles would be equivalent, the last two lines could
not be guaranteed. Moreover, even completely unrelated lookups of still
valid handles could break, since the internal ordering (e.g. as a
red-black tree) of the map suddenly changed from the outside.

  Regarding partial invalidation (some handles stay valid, others not),
I still would prefer to forbid this. But even if we leave this to an
implementation, we still need to differentiate the cases (*) and (**)
shown above.

Hopefully, that clarifies the requirements for our shiny little
operator< :-).

Greetings from Oldenburg,
Philipp

On 18/05/10 11:02, Bishnupriya Bhattacharya wrote:
> John,
>
> You are right. In the case of a freshly created and unassigned process handle, indeed its unique id will change once the handle is assigned to a process instance. Actually it is even more than that - the process handle's unique id will change whenever it is reassigned.
>
> sc_process_handle p, q;
> assert(!(p < q) && !(q < p)); // p and q are equivalent
>
> p = sc_spawn(...);
> assert((p < q) || (q < p)); // p and q are not equivalent
>
> q = sc_spawn(...);
> assert((p < q) || (q < p)); // p and q are not equivalent
>
> p = q;
> assert(!(p < q) && !(q < p)); // p and q are equivalent
>
> It seems then that a process handle can only be used successfully as the key in a map, iff such a handle is not used unintialized, and is not reassigned once it is initlialized. It maybe likely that a fair amount of applications fall under this category? Even for such usage, we need the property that an initialized process handle retain its unique id when the underlying process instance dies - which is really the difficulty we are trying to overcome in trying to use the raw process ptr as the key.
>
> I would like to hear from Philip on this topic - since he had originally proposed the motivation for operator <.
>
> BTW, on the side topic of clarifying the LRM to not allow an implementation to invalidate some handles but not others when the underlying process instance dies, where do we stand?
>
> Thanks,
> -Bishnupriya
>
>
>
>
> ________________________________
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Tuesday, May 18, 2010 1:00 AM
> To: Bishnupriya Bhattacharya
> Cc: Philipp A. Hartmann; systemc-p1666-technical@eda.org
> Subject: RE: Proposal for sc_process_handle: AGREE
>
> Bishnupriya, Philipp,
>
> Re. stability, I admit I'm confused. I think you want:
>
> sc_process_handle p, q;
> sc_assert( !(p < q) && !(q < p) );
>
> p = sc_spawn(...);
> sc_assert( (p < q) || (q < p) );
>
> Hasn't p just jumped around the map? I'm also anchoring my thinking in the implementation of a unique id, but the id belongs to the process instance, not the process handle. When a handle is newly created, you cannot second guess which id it will get. Once a handle is associated with a process instance everything works fine, because the handle can just keep the id of the instance, regardless of its validity.
>
> John A
>
[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.