Re: Wording proposal for request_safe_update

John,

Well, we have lots of "regular" threads in SystemC models already. Wrt.
to these SC_THREADs, "request_update" is already perfectly safe.

That's why I think a 'request_thread_safe_update' may be misleading.
But if the wording in the LRM is clear enough, I can of course live with
this name as well.

Greetings from Oldenburg,
Philipp

On 24/11/10 12:37, john.aynsley@doulos.com wrote:

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