Re: Identifying quickly what is the current process

Stuart, John, Jerome,

actually, your proposal just works fine indeed. I've actually used
something like this quite recently ...

  I took the opportunity to hack up a simple example of doing some stats
based on a vector< pair< sc_process_handle, int > >, which is attached
to this mail.

  The main issue with using a std::map of plain process object pointers
is, that they can become dangling once the process has been terminated.
 With the process_handle, you still have the valid() check.

  Unfortunately, you can't use the sc_process_handle class as a key in a
map directly, since it doesn't provide an ordering. But regarding the
presence of invalid handles, I don't easily see an implementation for
such an ordering.

  Since such sets of processes are quite likely to be small enough, I
don't see an immediate performance issue compared to the linear search
in a vector (see my example), though. It might be interesting to have a
benchmark of a vector container against a map of process object
pointers, though. :-)

  I think, if there's a need for an extension of the class
sc_process_handle at all, then the addition of a

  bool before( sc_process_handle const& ) const

function (or an operator< directly), that provides a strict weak
ordering and can be used within/as a comparator for std::map/std::set.

Just my 2¢,
Philipp

On 11/03/10 22:55, Stuart Swan wrote:
> John, Jerome-
>
> You still haven't convinced me that what I propose won't solve Jerome's issue.
>
> John- agreed that you are permitted multiple process handles to the same process,
> but if you use == for two such handles it will return true, which is what Jerome wants I believe.
> Jerome proposes to just use the handle object in the vector, but concludes that he can't because
> the ctor is private, but I believe it will all work fine..
>
> -Stuart
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Thursday, March 11, 2010 9:36 AM
> To: Stuart Swan; Eric PAIRE; Jerome CORNET
> Cc: 'Laurent MAILLET-CONTOZ'; owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
> Subject: RE: Identifying quickly what is the current process
>
> Stuart, Jerome,
>
> Nah, the copy ctor is public but it duplicates the process handle. You are permitted multiple process handles to the same process.
>
> But my answer to Jerome is to simply use the value returned from sc_process_handle::get_process_object() , which is the address of the process object itself, as the unique id. (You can then use std::map to get an integer id, if you like.)
>
> John A
>
>
> From:
>
> Stuart Swan <stuart@cadence.com>
>
> To:
>
> Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
>
> Cc:
>
> Eric PAIRE <eric.paire@st.com>, "'Laurent MAILLET-CONTOZ'" <laurent.maillet-contoz@st.com>
>
> Date:
>
> 10/03/2010 22:04
>
> Subject:
>
> RE: Identifying quickly what is the current process
>
> Sent by:
>
> owner-systemc-p1666-technical@eda.org
>
>
> ________________________________
>
>
>
> Jerome-
>
> I may be mistaken, since it has been a few years since I dug into this code,
> but I think you may be able to use the sc_process_handle object itself as the
> unique identifier that you seek. I think the copy ctor is public, and the object
> itself is very lightweight so it does not consume much time or space to copy it.
>
> One issue with having the integer ID that you propose at bottom is whether such
> integer IDs would ever be recycled when the original process dies. With the process_handle
> approach above there is no such issue. Plus, you get easy access to the process name, etc.
> And, with the process control extensions that Cadence has proposed for this update, you get
> additional functionality like kill, etc.
>
> Let me know if this doesn't work for you.
>
> Thanks
> -Stuart
>
>> -----Original Message-----
>> From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf
>> Of Jerome CORNET
>> Sent: Wednesday, March 10, 2010 6:16 AM
>> To: systemc-p1666-technical@eda.org
>> Cc: Eric PAIRE; 'Laurent MAILLET-CONTOZ'
>> Subject: Identifying quickly what is the current process
>>
>> All again,
>>
>> there are various situations where knowing what is the current process
>> (if any) is important.
>> For instance, one could want to compute statistics on a per SystemC
>> process basis.
>> The current norm standardized very useful APIs to get information about
>> what is the current process, with sc_get_current_process_handle() and
>> the sc_process_handle
>> class.
>>
>> However, there is no convenient and efficient way to understand what is
>> the current process
>> compared to previous invocations of sc_get_current_process_handle(). As
>> an example, let us
>> imagine I want to gather statistics about all processes in the
>> simulation. I would build an array
>> whose index would be a "process identifier" and that would contain my
>> "per-process" stat.
>>
>> - The const char * returned by name() in sc_process_handle could be a
>> candidate to this "process identifier",
>> but this is rather inefficient (many string compare to understand in
>> which array index I already
>> stored my stat.,
>>
>> - The adress of the sc_process_handle object cannot be taken as
>> "process identifier" as one could
>> have two different sc_process_handle representing the same process
>> information,
>>
>> - There is also the operator== that allows to compare whether two
>> process handle actually represent
>> the same process's information. This would oblige to use the
>> sc_process_handle object itself (and not
>> a pointer to it) as the process indentified, which is not very
>> convenient, especially if you want to use a STL container
>> for the array (I guess that the copy constructor is private, which means
>> no std::vector, etc., etc.).
>>
>> So we want to propose to add a method to the sc_process_handle class,
>> that could be as below:
>>
>> uint64_t id() const;
>>
>> and that could return a unique integer identifier associated with the
>> process. Hence, it would be
>> possible to retrieve and compare very quickly in what is the current
>> process.
>>
>> Jerome Cornet
>> STMicroelectronics

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