Re: Identifying quickly what is the current process

On 17/03/10 18:28, john.aynsley@doulos.com wrote:
> What do you guys plan doing with your operator< ?

Put it as a key in an associative container. :-)

> If you just want to use the sc_process_handle as the key to a std::map,
> then the following definition works fine (I've tried it)
>
> bool operator< (const sc_process_handle& r) const { return
> (*this != r) && (this < &r); }

This does not define a strict weak ordering (because it's neither
reflexive and not transitive), so you get undefined behaviour in your
program.

More precisely: The handles are copied to the map, so your address check
in operator< is quite random, even when logically pointing to the same
process instance.

> typedef std::map<sc_process_handle, int> map_t;
>
> Of course, you can then end up with multiple handles to the same process
> in the map, which is not what Jerome originally wanted.

Which is definitely not what I want. We should clearly define to
handles to be equivalent (!(a<b) && !(b<a)), if they point to the same
process instance.

> Any container that is keyed off the sc_process_handle is potentially going
> to contain duplicates (several handles for the same process)
> unless you perform a search before inserting a new key

Which somewhat defeats the purpose, right?

> and any container that is keyed off a unique process id (the address is as
> good as anything) is potentially going to contain dead processes.

Yes. In fact, that's what the recent discussion was about: how to
guarantee a stable ordering, even _if_ there are suddenly dead processes
(with invalidated handles !) in the map.

See my other mail for a proposal. :-)

Greetings from Oldenburg,
Philipp

> From:
> Stuart Swan <stuart@cadence.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "Philipp A. Hartmann"
> <philipp.hartmann@offis.de>, Bishnupriya Bhattacharya <bpriya@cadence.com>
> Cc:
> 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:
> 15/03/2010 16:39
> 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, and is
believed to be clean.