Re: Identifying quickly what is the current process

Agreed with Philipp.

Jerome

On 3/17/2010 6:38 PM, Philipp A. Hartmann wrote:
> 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
>>
>>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.