How to yield control from SystemC thread to another thread

[katang]

As I mentioned in a previous post, I want to display the state of the simulated object in a GUI thread, while the simulation thread is suspended. Can I do that in an elegant way?

I mean, that if I am after receiving my event, the event queue is empty, so the simulation stops immediately. If I suspend it before triggering the event,  then the  event queue is empty again; so my waiting terminates again. If I trigger the event first, then I stop at a wait(resume-event), the simulation goes to serve the event first, I wanted to stop at; and comes back to my wait(resume-event), and since the event queue is empty, stops again. I guess I need to forcefully prevent taking out the event before the GUI thread returned a resume_event. How can I do that?

[David Black]

Keep in mind that SystemC's kernel is not threadsafe. SC_THREAD and SC_METHOD processes are completely different animals than OS threads as well. You can use the async_request_update() method to interface into SystemC from the outside. From the inside you can of course stall everything in the SystemC side because it is cooperative multitasking system. In either case, you will need to use appropriately setup mutex to protect shared resources. Due to differences in the concept of time (simulated vs real), you will also likely need to use mailboxes for communication.

You might also what to consider scheduling events to happen at the end of a delta cycle (ie. event.notify(SC_ZERO_TIME) or perhaps even a non-zero time in the future.

[Eyck]

When implementing some simulation control I usually have the logic as part of a SC_THREAD. Once the thread is active it is save to access all the other data structures as -like @David Black mentioned- SystemC is cooperative multi tasking. Based on the GUI thread you can then decide to run for a certain time, until a certain event, or stop simulation entirely using sc_stop()

 

[katang]

My case is less complex. I am aware of that this process is not that process, and this scheduler is not that scheduler. My intention is exactly just to stall SystemC at some point of execution, and just to read some variables for displaying it in the GUI. I am interested in sc_time only from the aspect to display it in the GUI. I do not want any other communication, than emitting a message that SystemC stalled, then -- after finishing the GUI update -- to resume it. A kind of breakpoint. In the same way as used in a debugger. To resume, I can ask the thread to send a message. I wonder if I can stall SystemC safely, without interfering with anything.

Maybe SC_ZERO_TIME solves the problem; however the simulation itself also uses SC_ZERO_TIME in some cases; so they may interfere; I need to check.  I do not want to use non-zero time as it falsifies the simulation time, which is also important.

 

[katang]

So you say that rather than stalling in SystemC, I need to wait for a SystemC event generated by the GUI? then the SystemC thread can emit a signal, and the two guys can ping-pong with the signals? It sounds good, thank you.

That is, as @David Blacksuggested, I shall use the async_request_update() method from the thread, running SystemC? Is some sample around? in the book and the examples I do not find a call like this.