Re: Wording proposal for request_safe_update

See below.

On Wed, Nov 24, 2010 at 4:31 AM, <john.aynsley@doulos.com> wrote:

> David,
>
> Two questions.
>
> You write
> " 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."
>
> In a sense, the implementation cannot even guarantee that, can it? What
> does it mean for a call in another O/S thread to happen in the current delta
> cycle? The thread might be executing on some remote core with some
> communication delay to the physical or virtual core running the SystemC
> kernel. We don't know what the memory architecture looks like. I think all
> that is guaranteed is that request_thread_safe_update does not break the
> kernel. Whether and when the call arrives at the SystemC kernel at all is a
> different matter.
>

You are correct. We can only guarantee that a call the
request_thread_safe_update() will not break the kernel and the request will
get through. I mean if it gets in and executes, it is guaranteed to work.
The timing is the unknown aspect.

> 2nd question: Are there any dependencies or interactions between
> request_update and request_thread_safe_update? Can you have both for the
> same primitive channel instance? What happens?
>

Good point, I think it should be stated that it is undefined if both are
called. Choose one or the other.

> Thanks,
>
> John A
>
>
>
> From:
> David C Black <dcblack@xtreme-eda.com>
> To:
> systemc-p1666-technical@eda.org
> Date: 21/11/2010 08:52 Subject:
> Wording proposal for request_safe_update
> Sent by: owner-systemc-p1666-technical@eda.org
> ------------------------------
>
>
>
> 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.