Re: Identifying quickly what is the current process

All,

sorry about the misleading std::vector stuff (indeed the copy
constructor is public in the norm, etc.).

Let us recap:

- The pointer to the sc_object 'process' returned by
sc_process_handle::get_process_object()
could be used as a key in an array/map container. However, the main
drawback is that the
pointer becomes invalid if the process dies. And... the valid status (as
well as other informations
on the process) is unfortunately in the sc_process_handle, which is a
logical good candidate to
"uniquely identify" a process.

- sc_process_handle has some minimal functions that allows to use it as
process identifier (such
as operator== as I mentioned in my first email). However, as I said in
my first email, this is not
convenient, as the std::map example of Philipp shows. You indeed need
operator< to be declared,
not ==.
For sure, in this particular case, the user could provide his own
functor relying on sc_process_handle's
  operator== and valid(), but why not providing the necessary operator<?

For me, Philipp's proposal of operator< is also a good solution.
Having a unique process id as integer as I proposed is another solution.

Jerome

On 3/12/2010 12:40 AM, Philipp A. Hartmann wrote:
> 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
>>>
>

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