Thread safety proposal

In order to support the use-case where an application would like to
asynchronously interface with a running systemc simulation, I would like to
propose a small enhancement. Before I dive into the details here are a few
of applications illustrating the issue:

*PROBLEM USE CASES*

1. Remote application uses shared memory, and synchronizes with the running
simulation by sending POSIX signals (e.g. SIGINT or SIGUSR1). I illustrated
this at NASCUG with a presentation on how we implemented a virtual MPU for a
client. Signal handler generated a systemc event. We created a primitive
channel and used request_update()/update(), and were able to demonstrate by
way of missed events that SystemC is not thread safe. A work-around using a
timeout was used; however, the results were not very satisfactory.

2. Remote application interfaces to systemc process (SC_THREAD or SC_METHOD)
via sockets and updates come in asynchronously to a real OS thread. Thread
needs to send an event to systemc process to allow processing to proceed.
Again, we have missing events or odd timeouts with queues either starving or
filling.

*SOLUTION DETAILS*

In order to minimize overhead, we suggest the creation of a new method, *
sc_prim_channel::request_safe_update*(void) and corresponding support during
perform_update(). The pair shall maintain a list of requested safe updates.
When placing a new request into the set of sc_prim_channel requests
(currently implemented as a linked list), request_safe_update() shall be
obligated to do so in a thread safe manner. On the other side, when code
performing the udpates grabs the information, it shall be obligated to
remove the information in a thread safe manner. It is recommended that OS a
scoped mutex be used for implementation.

*PROOF OF CONCEPT*

We have implemented the above solution in a version of the OSCI PoC
simulator implementation and tested result successfully. The mutexes are
only used for safe updates and so stay out of the way of normal
sc_prim_channels. By careful coding, we are able to keep the additional
overhead for normal primitive channels to less than 1% (measured of 1e6
sc_signal update/events). Since most SystemC designs use a lot of high level
constructs and tend to minimize sc_prim_channel access, we believe the
effective overhead will be substantially less than even the measured value.

Before settling on this solution, we tried several implementation
approaches. We also considered alternate areas of the simulator to affect,
but they always came out more complicated that we hoped.

*DONATIONS*

We have donated code patches to OSCI (by way of Andy Goodrich) implementing
the new mechanism. It supports both POSIX mutexes and Microsoft Windows
mutexes; albeit, the Windows solution is untested. An alternate solution
involving BOOST mutexes was omitted due to the complexity of including more
BOOST code into the PoC simulator.

In addition to the code patches, we will be submitting two tests for
inclusion: 1. verifies the new functionality by implementing a thread safe
event channel using the new request_safe_update() mechanism, 2. verifies the
simulation overhead difference by running millions of normal events whose
run-time can be compared with the unmodified version of SystemC.

Respectfully,
David C Black, ESL Practice Leader
XtremeEDA Corporation

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