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, and is
believed to be clean.