Re: Wording proposal for request_safe_update

Philipp,

I take your point that 'request_thread_safe_update' does not express the
use case, but it does express exactly what the function does: it is like
request_update except that it is thread-safe. So I think the name
expresses the intent as well as anything.

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>, "Jeremiassen, Tor" <tor@ti.com>, David
C Black <dcblack@xtreme-eda.com>, bpriya@cadence.com
Date:
24/11/2010 10:46
Subject:
Re: Wording proposal for request_safe_update

John, All,

'request_thread_safe_update' does not really express the intended
use-case. It shall be used, when called from 'outside the kernel' or
asynchronously to the kernel's scheduler.

So, I would go for something like
  async_request_update
  external_request_update

Greetings from Oldenburg,
  Philipp

On 24/11/10 10:58, john.aynsley@doulos.com wrote:
> Fine. I will write up David's proposal.
>
> Do we want to go with request_thread_safe_update() as suggested by
> Bishnupriya? I would slightly prefer that.
>
> John A
>
>
>
>
> From:
> Jerome CORNET <jerome.cornet@st.com>
> To:
> "Jeremiassen, Tor" <tor@ti.com>, "john.aynsley@doulos.com"
> <john.aynsley@doulos.com>
> Cc:
> David C Black <dcblack@xtreme-eda.com>,
> "owner-systemc-p1666-technical@eda.org"
> <owner-systemc-p1666-technical@eda.org>,
"systemc-p1666-technical@eda.org"
> <systemc-p1666-technical@eda.org>
> Date:
> 23/11/2010 15:24
> Subject:
> RE: Wording proposal for request_safe_update
>
>
>
> I concur with Tor: this is separate from the parallelization discussion
> on-going in the LWG.
>
> Best regards,
>
> Jerome
>
> From: Jeremiassen, Tor [mailto:tor@ti.com]
> Sent: Monday, November 22, 2010 6:21 PM
> To: john.aynsley@doulos.com
> Cc: David C Black; Jerome CORNET; owner-systemc-p1666-technical@eda.org;

> systemc-p1666-technical@eda.org
> Subject: RE: Wording proposal for request_safe_update
>
> I believe this is a separate issue from the parallel SystemC discussion
> and should be standardized now.
>
> Best regards,
>
> Tor Jeremiassen
>
> ---
> Tor Jeremiassen, Ph.D.
> Simulation and Modeling CTO
> SDO Foundational Tools
> Texas Instruments Ph: 281 274 3483
> P.O. Box 1443, MS 730 Fax: 281 274 2703
> Houston, TX 77251-1443 Email: tor@ti.com
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Monday, November 22, 2010 10:00 AM
> To: Jeremiassen, Tor
> Cc: David C Black; Jerome CORNET; owner-systemc-p1666-technical@eda.org;

> systemc-p1666-technical@eda.org
> Subject: RE: Wording proposal for request_safe_update
>
> All
>
> Clearly there is some support for David's proposal. The only question is

> whether this should be punted to the LWG for consideration alongside the

> parallel SystemC discussion or whether we are ready to go for IEEE 1666
> standardization right away.
>
> What do people think?
>
> John A
>
>
> From:
> "Jeremiassen, Tor" <tor@ti.com>
> To:
> Jerome CORNET <jerome.cornet@st.com>, David C Black
> <dcblack@xtreme-eda.com>, "systemc-p1666-technical@eda.org"
> <systemc-p1666-technical@eda.org>
> Date:
> 22/11/2010 14:00
> Subject:
> RE: Wording proposal for request_safe_update
> Sent by:
> owner-systemc-p1666-technical@eda.org
>
>
>
>
>
> All,
>
> TI fully supports the proposal for request_safe_update.
>
> Tor
>
> ---
> Tor Jeremiassen, Ph.D.
> Simulation and Modeling CTO
> SDO Foundational Tools
> Texas Instruments Ph: 281 274 3483
> P.O. Box 1443, MS 730 Fax: 281 274 2703
> Houston, TX 77251-1443 Email: tor@ti.com
>
>
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jerome CORNET
> Sent: Monday, November 22, 2010 7:05 AM
> To: David C Black; systemc-p1666-technical@eda.org
> Subject: RE: Wording proposal for request_safe_update
>
> All,
>
> I am fully in favor of the proposal, which has the advantage of
simplicity
> (and for which an implementation is proposed).
> At ST, we have previously envisaged to make a different proposal,
> involving callbacks of the scheduler, but we have decided it would be
> beneficial
> and simpler to converge on David?s. Just a note to say that we are
dealing
> with the same kind of use cases [as described in David?s previous email]

> here.
>
> Regards,
>
> Jerome
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of David C Black
> Sent: Sunday, November 21, 2010 9:52 AM
> To: systemc-p1666-technical@eda.org
> Subject: Wording proposal for request_safe_update
>
> I believe my proposal should have the following effects:
> Change most references to "request_update" to read "request_update or
> request_safe_update". In some text when referring to to "request_update
> and update", use the language "request_update, request_safe_update and
> update"
> In section 6.15.1 (page 135) insert a line after "void
request_update():"
> void request_safe_update();
> In section 6.15.6 (page 136), retitled "request_update,
> request_safe_update and update" add:
> void request_safe_update();?
> Member function request_safe_update shall cause the scheduler to? queue
> an update request for the specific primitive channel instance making the

> call. It differs from request_update in that it will? implemented in an
> OS thread safe manner that allows it to be called reliably from outside
> the simulator OS thread. It may have a performance degradation relative
to
> request_update due to the use of mutex or other mechanisms for thread
> safety.
>
> Potentially add
> NOTE 3 - Due to the asynchronous nature of calls to request_safe_update,

> it is necessary that code implementing the update phase must take care
> when handling updates from the set of safe update requests. It is
possible
> for a request_safe_update call to be made at anytime from start of
> simulation including during the update phase.
> NOTE 4 - There shall be no guarantees as to whether a call to
> request_safe_update shall be acted upon in the current delta cycle or
the
> one immediately following. It is only guaranteed that the request will
> honored within one of two possible delta cycles, the current one or the
> one following.
> NOTE 5 - request_safe_update is not recommended for use in normal
> sc_prim_channel's, and should be reserved to channels requiring
> asynchronous interface to the simulator itself.
>
> I'm not sure much else needs to be added.
>
> David
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.