RE: Wording proposal for request_safe_update

All,

I'm in favor of David's proposal - the use cases are genuine, and we have also run into this issue.

One input: perhaps name request_safe_update() a little more verbosely like request_thread_safe_update() or something similar, that better captures the intent?

Thanks,
-Bishnupriya

________________________________
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 2:22 PM
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



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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