RE: Identifying quickly what is the current process

Quick question.

Could two dynamically spawned processes with non-overlapping lifetimes use the same name? Or is there something in the standard to prevent this?

Tor

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Stuart Swan
Sent: Monday, March 15, 2010 11:39 AM
To: john.aynsley@doulos.com; Philipp A. Hartmann; Bishnupriya Bhattacharya
Cc: Eric PAIRE; Jerome CORNET; 'Laurent MAILLET-CONTOZ'; systemc-p1666-technical@eda.org
Subject: RE: Identifying quickly what is the current process
It wouldn't work right since process handles in SC are like object handles
in Java or SV - ie two handles pointing to the same object are equivalent.
Also - if possible I'd like operator< to work reproducibly the same way on different
implementations and platforms.
Since operator< will be called quite rarely, I think just using the full hierarchical name
of the process is sufficient. On first call, we copy the name from the process object to the handle,
so that if the process terminates then subsequent calls to operator< still work and return the same result.
-Stuart
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, March 15, 2010 2:18 AM
To: Philipp A. Hartmann
Cc: Eric PAIRE; Jerome CORNET; 'Laurent MAILLET-CONTOZ'; Stuart Swan; systemc-p1666-technical@eda.org
Subject: Re: Identifying quickly what is the current process
What's wrong with using the address of the process handle to define operator<?
John A
From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
Stuart Swan <stuart@cadence.com>
Cc:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, Eric PAIRE <eric.paire@st.com>, Jerome CORNET <jerome.cornet@st.com>, 'Laurent MAILLET-CONTOZ' <laurent.maillet-contoz@st.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
12/03/2010 23:15
Subject:
Re: Identifying quickly what is the current process
________________________________
Stuart, All,
see my reply below.
On 12/03/10 23:23, Stuart Swan wrote:
>>
>>  Two invalid handles (with internal pointers being NULL) are then
>> considered equivalent (a<b == false && b<a == false), which is OK for
>> the total ordering, I think.
>
> But isn't there a problem that the ordering between two processes then
> changes between the time when the processes are alive and then one or
> both terminates ?  For sorting within maps etc the ordering needs to remain
> constant , right ?
Indeed, this would be a problem.
 I once again noticed, that one should always look in the standard,
instead of relying on a particular implementation.  In the OSCI
implementation, a terminated process does not invalidate any of its
handles, so my approach works fine there.
But in 5.6.5 it says e.g. for the terminated() function:
 When the underlying process instance terminates, an implementation
 may choose to invalidate any associated process handles but is not
 obliged to do so. In other words, when a process terminates, an
 implementation is neither obliged to keep the handle valid nor to
 invalidate the handle.
 So the naïve implementation relying on a handles validity only works
for those implementations, that keep the handles valid after the
termination of their processes.  It's therefore even more important to
standardize a stable operator<,  that guarantees a total order
regardless of a handle's validity.  The rest are implementation details
... ;-)
>> So the implementation could simply look like (based on the OSCI
>> implementation):
>>
>> inline bool operator < (
>>    const sc_process_handle& left, const sc_process_handle& right )
>>  { return left.m_target_p < right.m_target_p; }
>
> But this is not portable (ie won't necessarily give same result) across
> different platforms or simulators. Would be nice if we could make it portable..
 If you mean by portable something like "predictable across runs and
implementations", yes this would not be the case.  I'm somewhat
reluctant to rely on name comparisons though.  Firstly, the handle would
need to keep a copy of the name somewhere, even if the process has been
deleted (which is currently not the case).  Secondly, this would make
comparisons quite costly.
 What benefit do you see in a predictable ordering?  The most common
use case is to use handles in something like a map/set.  There, the
exact position is usually not of much interest.  Am I missing something?
 A possible implementation for such a (somewhat) predictable ordering
would in fact be something like an internal process id, as originally
proposed by Jerome.  If it is not reused, even if ids are "free" due to
terminated processes, it should be fine as a total ordering again.
Still, if the scheduling, and therefore the order of creation of the
processes varies between different runs or across implementations, a
real determinism can (and should) not be guaranteed.
 I think, we should define such an operator< simply according to the
requirements for a strict weak ordering from the C++ standard, enabling
the handle as a key in a map even after the process has been
deleted/terminated.  IMHO, it should not be part of the standard whether
implementations choose to keep handles valid after process termination
or implement a stable ordering through other techniques.
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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.