RE: Identifying quickly what is the current process

I also like the idea of adding sc_process_handle::operator< also, but I'm not quite
sure how it would be defined. Would the comparison be based on the full process name,
if the process handle is valid ?

Thanks
Stuart

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, March 12, 2010 6:34 AM
To: Stuart Swan
Cc: Eric PAIRE; Jerome CORNET; 'Laurent MAILLET-CONTOZ'; owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
Subject: RE: Identifying quickly what is the current process

Stuart,, All,

You're right. I had not noticed operator==.

Contrary to my last email, I do agree that sc_process_handle is better than the process object pointer as a unique key. I quite like the proposal of sc_process_handle::operator<

John A

From:

Stuart Swan <stuart@cadence.com>

To:

"john.aynsley@doulos.com" <john.aynsley@doulos.com>, Eric PAIRE <eric.paire@st.com>, Jerome CORNET <jerome.cornet@st.com>

Cc:

"'Laurent MAILLET-CONTOZ'" <laurent.maillet-contoz@st.com>, "owner-systemc-p1666-technical@eda.org" <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>

Date:

11/03/2010 21:57

Subject:

RE: Identifying quickly what is the current process

________________________________

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.

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