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.