Re: Proposal for sc_process_handle

Philipp,
 
Re. the wording, you can leave that to me (though I appreciate any suggestions).
 
Re. the reincarnation, I'm not so sure (though I haven't thought about it in great depth). When a process dies, any handles are invalidated, and operator== would return false when comparing two handles both of which point to the same corpse. But the ordering would still be based on the dangling pointers.....
 
Cheers,
 
John A

 
-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----

To: john.aynsley@doulos.com
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 03/18/2010 06:12PM
Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: Proposal for sc_process_handle

On 18/03/10 12:22, john.aynsley@doulos.com wrote:
> Whoops. If a dead process object gets reincarnated as another process with
> another handle, haven't we got a problem? The new process would have
> equivalent ordering to the dead process, no?

Hmmm, I think this shouldn't be a problem. At least, it has to be
consistent with operator==, right?

  If it's really the same process object, then the handles would've been
valid all the time (even though temporarily terminated). New handles,
that still compare equal to the old ones are naturally ordered in the
same way, as they still point to the same (now maybe reincarnated)
process object.

  If its a new process object (with new handles comparing unequal to the
old handle), then a different ordering is both expected and required, I
think.

> From: john.aynsley@doulos.com
[snip]
> Date: 18/03/2010 11:09
[snip]

> Agreed. Cool. Swap too.

Glad to hear. :-)

> I would probably want to spell out "strict weak ordering" and "collation
> order" rather than relying on familiarity with the C++ standard.

Ok. I can try to provide an updated/more explicit wording. But this
will have to wait until next week, as I'm quite busy (and out of
office) until Tuesday, I suppose.

> Just to be concrete, the following implementation...
>
> bool operator< (const sc_process_handle& r) const {
> return this->get_process_object() < r.get_process_object();
> }
>
> would work fine, provided the implementation left the dangling pointers
> unchanged following invalidation, right?

Exactly.

Greetings from Oldenburg,
Philipp

> (But I agree that the
> implementation should be free to implement "strick weak ordering" however
> it likes, and I agree the order could vary from run-to-run.)

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