Will SC_THREAD in SystemC create a real thread?

Question

I debugged following code in Visual Studio 2008 (64 bit) by setting break point at the start of do_test1 and do_test2, to my suprise, the code is running in the same thread of the sc_main function.

I didn't debug in Linux environment. However, by searching the source code, I found the "pthread.h" was included by some SystemC library source code.

Question 1: In Windows, will the SC_THREAD create a real thread? Or it is always in the same thread of sc_main? If this is the case, may I say SC_THREAD is creating a "fake" thread?

Question 2: In Linux, since "pthread.h" is included, will SC_THREAD create a new thread?

Question 3: In Windows and Linux, did I miss some settings to enable the real thread?

========================================

Following code is from this website:

http://www.asic-world.com/systemc/systemc_time4.html#Example_:_sc_event

    #include <systemc.h>

    SC_MODULE (events) {
      sc_in<bool> clock;

      sc_event  e1;
      sc_event  e2;

      void do_test1() {

        while (true) {
          // Wait for posedge of clock
          wait();
          cout << "@" << sc_time_stamp() <<" Starting test"<<endl;
          // Wait for posedge of clock
          wait();
          cout << "@" << sc_time_stamp() <<" Triggering e1"<<endl;
          // Trigger event e1
          e1.notify(5,SC_NS);
          // Wait for posedge of clock
          wait();
          // Wait for event e2
          wait(e2);
          cout << "@" << sc_time_stamp() <<" Got Trigger e2"<<endl;
          // Wait for posedge of clock
          wait();
          cout<<"Terminating Simulation"<<endl;
          sc_stop(); // sc_stop triggers end of simulation
        }
      }

      void do_test2() {
        while (true) {
          // Wait for event e2
          wait(e1);
          cout << "@" << sc_time_stamp() <<" Got Trigger e1"<<endl;
          // Wait for 3 posedge of clock
          wait(3);
          cout << "@" << sc_time_stamp() <<" Triggering e2"<<endl;
          // Trigger event e2
          e2.notify();
        }
      }

      SC_CTOR(events) {
        SC_CTHREAD(do_test1,clock.pos());
        SC_CTHREAD(do_test2,clock.pos());
      }
    }; 

    int sc_main (int argc, char* argv[]) {
      sc_clock clock ("my_clock",1,0.5);
      events  object("events");
        object.clock (clock); 
      sc_start();  // Run the simulation till sc_stop is encountered
      return 0;// Terminate simulation
    }

Answer 1

No & Yes. It depends on your SystemC library configuration.

You can configure SystemC to use pthread or Windows native thread. So when you compile and run your SystemC design, it creates REAL threads. However, by default, in UNIX environment, it won't use pthread by default because system calls are expensive. And SystemC only run threads one by one no matter how you configure your SystemC to use pthread or Window native thread. Because it only runs one thread at a time, using its user-level thread is faster than others because no system-calls are involved.

Why SystemC does not run all schedule threads at once? It's another question.

Answer 2

Short answer:

Threading libraries, be they user-level threads (lighter and faster for context switching ) or kernel-level threads, are not used to provide real concurrency. Rather, they are used to implement coroutine semantics of SC_THREAD processes.

Long answer:

SystemC has 3 types of processes (i.e., units of concurrency), the most important of which are only two:

1. SC_METHODs are methods (similar to always statements in Verilog) that execute in their entirety in zero time when triggered by an event. They cannot use wait to wait for a time interval or event occurrence.
2. SC_THREADs are methods (like initial statements in Verilog) that execute only once, but they can use wait to wait for particular events or periods of time, and can use loops to emulate always statements (so an SC_THREAD can consume time).

For an implementation perspective, there is no problem with SC_METHODs because they are just like methods registered with the SystemC kernel to be called when triggered. However, for SC_THREADs, although they are defined as member functions, their behavior is not like ordinary routines. They are called coroutines:

Subroutines that allow multiple entry points for suspending and resuming execution at certain locations.

The SystemC kernel doesn't furnish real concurrency for system-level or RTL models. It only offers simulated concurrency through the process construct. Therefore, when writing high-level models, you don't have to use synchronization primitives (e.g., locks or semaphores) to protect data shared by different processes, since at any one time, only one process is executing and it cannot be aborted by the SystemC kernel (execution switches to the next process ready to execute only when the currently executing process relinquishes control. Still synchronization can be used, but SystemC promotes the use of message passing in channels for communication among processes. This is an advantage, since it reduces complexity. However, there are disadvantages too. SystemC models execute sequentially (not parallelized) so they don't utilize multicore architectures to speed up simulations. This is a hot research area where simulation performance is desired.

Anyway, the SystemC kernel thus implements cooperative scheduling, where each SC_THREAD willingly relinquishes control (by using wait) to allow other SC_THREAD processes to execute. If you have an infinite loop inside an SC_THREAD process that never relinquishes control, the whole simulation will be stuck there and simulation time won't advance. The same is true about SC_METHODs, which must return for the SystemC kernel to regain control.

In order to implement that cooperative scheduling strategy using coroutines, a threading library is used (e.g., pthreads, or QuickThread which is included in the SystemC source code) to enable SC_THREAD's (launched as threads) to suspend themselves and enable the kernel to resume them later. Read this article to know more about this.