Event generation in systemc

I am trying to understand event generation in systemc. I found that it depends on the order of thread registration in constructor.

#include <systemc.h>                                                                                                   
    SC_MODULE(EventTest){                                                  
        sc_event ev1;
        void p1(){
           ev1.notify();
           ev1.notify(0, SC_NS);                                                                                    
        }

    void p2(){
        wait(ev1);
        cout<<"ev1 is activated at "<<sc_time_stamp()<<endl;           
        wait(ev1);
        cout<<"ev1-2 is activated at "<<sc_time_stamp()<<endl;         
    }
    SC_CTOR(EventTest){                                                
        SC_THREAD(p1);
        SC_THREAD(p2);                                       
    }   
};      

int sc_main(int argc, char *argv[]){                                   
    EventTest d("d");                                               
    sc_start();
    return 1;
}

output : ev1 is activated at 0 s

if i change the in SC_CTOR to >

SC_THREAD(p2);
 SC_THREAD(p1);

then output is >

ev1 is activated at 0 s
ev1-2 is activated at 0 s

Please someone tell how does the order of registration affect event generation?

Your code is composed of two SystemC processes (SystemC threads or methods are called processes), which are both SystemC threads : p1 and p2. They will be executed both during the first delta cycle of the simulation. However, SystemC standard has no guarantee about the running order of processes in a same delta cycle.

• If p1 is executed first, it does an untimed notification to the event ev1. See 5.10.6 section of IEEE Std 1666-2011.

  A call to member function notify with an empty argument list shall create an immediate notification. Any and all process instances sensitive to the event shall be made runnable before control is returned from function notify, with the exception of the currently executing process instance, which shall not be made runnable due to an immediate notification regardless of its static or dynamic sensitivity

  However, nothing is waiting the event. The notification does nothing. Then p1 does a timed notification. In that case, the behaviour is different :

  A call to function notify with an argument that represents a non-zero time shall create a timed notification at the given time, expressed relative to the simulation time when function notify is called. In other words, the value of the time argument is added to the current simulation time to determine the time at which the event will be notified. The time argument shall not be negative. NOTE—In the case of a delta notification, all processes that are sensitive to the event in the delta notification phase will be made runnable in the subsequent evaluation phase. In the case of a timed notification, all processes sensitive to the event at the time the event occurs will be made runnable at the time, which will be a future simulation time.

  Finally, the process p1 ends and p2 is executed. The first wait will suspend the process. The pending notification of the event is then propagated and will unlock the process p2. Then, the process p2 will execute the second wait and suspend again. As nothing will notify the event, the simulation will end.

• If p2 is executed first, it will suspend on the first wait. Then, p1 will be executed. It will do a first notification. As p2 was waiting the notification, p1 will be suspended (immediate notification) and p2 will continue and move on until the second wait. p2 is suspended. Then, p1 continue. It does the timed notification and the process ends. As p2 was waiting for the notification and it happened, p2 execution continue and the process ends. The simulation ends too.

Finally, in your two cases, p1 is always executed after p2 with the SystemC implementation you used. With another implementation of SystemC, it could be the reverse. You should consider they're executed in parallel at the same simulation time. In that case, both orders are right.

In the end, it means that your code can lead to a non deterministic behaviour.