RE: Proposal for sc_process_handle: AGREE

Good. Then I think we are done. I will write it up.

Thanks

John A

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

John,
 
I'm techically aligned with Philip on this issue - both on handle
equivalence rules and clarifying the LRM to not allow invalidation of only
SOME handles after process terminates.
 
Thanks,
-Bishnupriya

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, May 20, 2010 9:55 PM
To: Philipp A. Hartmann; Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org
Subject: Re: Proposal for sc_process_handle: AGREE

Philipp, Bishnupriya,

My bottom line: I am fine with that if we have a consensus.

I.E.

* Empty handles are equivalent (good point about copying empty handles)
* An implementation may invalidate handles or not, but (the new bit) must
invalidate handles consistently (cannot have valid and invalid handles to
the same process after termination)

John A

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

John,

On 18/05/10 22:17, john.aynsley@doulos.com wrote:
>
> 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.

Agreed.

 Although the term "uninitialized handle" is not very precise, since
the sc_process_handle class has a default constructor. So from a C++
point-of-view all handles are somehow initialized, maybe
default-initialized to an invalid/empty handle. Maybe we can use the
term "empty handle" for this special case?

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

I don't understand this. What is the perceived pitfall here (e.g.
compared to a map with raw pointers as keys)?

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

Yes, both is theoretically possible.

> 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?

What is the value of "sc_process_handle() < sc_process_handle()"?
Should it be constant? deterministic? random()? unspecified? ;-)

I would prefer (which makes empty handles equivalent):
 sc_assert( sc_process_handle() < sc_process_handle() == false );

Having a less restricted behaviour for this, IMHO requires additional
wording for copy constructor/assignment operator. Because copies of
handles should of course be equivalent (even for empty ones):

sc_process_handle p;
sc_assert( sc_process_handle(p) < p == false );

> I suppose it would affect the size of the map if there
> were a lot of uninitialized handles.

Exactly. It depends on the answer to the above question... :-)

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

Yes, we don't need to specify this due to operator<, if we define the
equivalence independently of the validity.

 Actually, the point in time of the invalidation relative to process
termination should not be restricted. BUT, invalidation itself should
be consistent. Given two valid, equal handles, once one of them becomes
invalid the other one should be invalid as well:

sc_process_handle p,q;

// two valid, equal handles
p = q = sc_spawn( ... );

// ... some time later ...

// OBSERVE invalidation of one of the handles
sc_assert( p.valid() == false );

// afterwards: OBSERVE a valid handle to the terminated process
sc_assert( q.valid() == true ); // Huh?!

We KNOW, that both handles once pointed to the same process, but we
suddenly can't use the handles interchangeably any more. This seems to
be very dangerous and counter-intuitive.

Greetings from Oldenburg,
Philipp

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