RE: Proposal for sc_process_handle: AGREE

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

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----

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

John, Philip,

I agree with Philip on both counts.

1) I had always implicitly assumed the LRM wording to mean that on termination of a process, an implementation may choose to invalidate ALL associated handles, or NONE. It had never occurred to me that the LRM wording implied an implementation is allowed to only invaldiate SOME handles. I do not see any rationale for allowing an implementation to only invalidate some handles, so I vote the LRM should explicitly make this illegal. Then the corner case you mention does not exist.

2) Even if it does exist, the < operator should not take into account validity. For the objective of the < operator to be fulfilled, it should simply compare the unique process id inside it, and return an answer based on that comparison, period. (I'm going down to implementation here, but that helps me stay deconfused). So if indeed there are 2 handles ponting to the same process instance - one valid and the other invalid - such handles are equivalent.

Thanks,
-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Monday, May 17, 2010 2:52 PM
To: john.aynsley@doulos.com
Cc: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
Subject: Re: Proposal for sc_process_handle: AGREE

John,

  I'm not sure, whether this corner case can (or should be allowed to) happen in an implementation. We could consider to to clarify the invalidation of handles in that regard, though.

Some comments embedded below.

On 14/05/10 15:01, john.aynsley@doulos.com wrote:
>
> In writing up sc_process_handle::operator< I've hit another corner case.
> First I'll re-state the rules we agreed, but reworded slightly:
>
> (1) 2 valid handles are equal iff they are equivalent:
[snip]

> (2) a valid and an invalid handle are never equivalent:
[snip]

> (3) 2 invalid handles are equivalent iff they formerly pointed to the
> same process or no process object
[snip]

> Now the problem. When a process terminates, an implementation may
> chose to invalidate a handle or not:

  If I understand you correctly, you assume that an implementation may invalidate only some of the handles of a terminated process. Is there any reason for an invalidating implementation not to invalidate all remaining handles?

  If we explicitly require, that either all or no handle is invalidated, the corner case you describe can't happen, right?

> sc_process_handle p, q;
> p = q = sc_spawn(...);
>
> wait( p.terminated_event() );
>
[snip]
> else // 1 handle valid, the other not
> {
> sc_assert( p != q ); // One handle is invalid
> sc_assert( (p < q) || (q < p) ); ??????

I think, we need to go with

   sc_assert( !(a<b) && !(b<a) );

here, see below.

> }
>
> Here we have two handles that point to the same process object, but
> only one of them has been invalidated. By (2) they are not equivalent.
> By (3) they would become equivalent once again when the 2nd handle
> gets invalidated!

> I guess we go in one of two directions:
>
> * Either we keep (2), in which case two invalid handles are always
> equivalent and (3) is wrong. Effectively there is an equivalence
> partition for all invalid handles

Unfortunately, this is not possible. This would break/change the relative ordering or handles when processes are terminated.

  As a result, the handle could NOT be used as a key within a map, since the internal ordering of the map is required to be stable. Otherwise, the lookup of a handle "behind" a now invalid handle could fail, leading to duplicates in the map, etcetc.

> * or two handles are equivalent iff they point or pointed to the same
> process, in which case (2) need to be re-worded so it only applies
> where the handles point to different processes.

  Independently of the validity of handles, two handles shall be equivalent, iff they point(ed) to the same or no process object.

> Personally I vote for the first option (keep (2)), because this is
> congruent with the fact that get_process_object() returns a null
> pointer for an invalid handle. Effectively all process handles with a
> null pointer are in the same equivalence partition.

  I would vote for the option to clarify the invalidation of processes to only invalidate all handles of a given process at once. Although the equivalence partition for invalid handles is nice, we need to differentiate invalid handles to keep the ordering stable.

Greetings from Oldenburg,
Philipp

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