Re: Wording proposal for request_safe_update

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.

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?

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, and is
believed to be clean.

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