Events notifications and wait for events

[amitk3553]

Constructor part in my code

hci_top(sc_module_name nm):sc_module(nm), ll_hci_tar_socket("ll_hci_tar_socket")

{

SC_THREAD(hci_ll_cmd_pkt_transmit);

hci_ll_cmd_thread = sc_get_current_process_handle();

 

ll_hci_tar_socket.register_b_transport(this, (&hci_top::hci_host_pkt_transmit));

}

 

In hci_host_pkt_transmit, i have notified an event like

evt_1.notify();

 

And I am waiting on this event in hci_ll_cmd_pkt_transmit like

wait(evt_1);

 

But wait is never ending, means evt_1 is not coming? Had I done something against scheduler operation here?

[ralph.goergen]

Hi. 

 

The never ending wait may be caused by race conditions. 

 

a) Notify with no argument means immediate notification. I.e., all processes sensitive to this event are made runnable in the same delta cycle. This may lead to non-deterministic behavior and should be used with care. 

 

Notify means all processes sensitive to this event are made runnable. The process in your case is sensitive to the event when its execution reaches the wait instruction. When the notify instruction is executed before the wait instruction is reached, no process is sensitive to the event. Event notifications are not stored for later waits. 

Assume the following example:

p1(){
wait(ev1);
cout << "wait done";
}

p2(){
ev1.notify();
}

When p1 starts first, it executes until wait is reached. Then p1 is suspended and p2 continues. The notification of ev1 is executed, p1 is made runnable again, and the message is printed. 

When p2 starts first, the notification of ev1 is done without any process waiting. Hence, it has no effect. Then p1 is started. It reaches the wait statement and will wait forever because the event notification has been executed before. No message will occur. 

Since SystemC contains no guaranty about the order in which processes runnable in the same delta cycle are executed, a model like the example leads to non-deterministic behavior. 

 

Greetings

Ralph

[apfitch]

The other perhaps obvious point is - have you got a loop in your thread(s)? If you haven't they will only run once then die.  Even with a loop, you could miss the first event for the reasons Ralph points out,

 

regards

Alan

[amitk3553]

"Since SystemC contains no guaranty about the order in which processes runnable in the same delta cycle are executed, a model like the example leads to non-deterministic behavior", but there would be something in SystemC to make processes run one after another.

 

Like I want process P1 run first, and then P2

 

p1(){

wait(ev1);
cout << "wait done";
}

p2(){
ev1.notify();
}

 

I had registered both in constructor, where they will run concurrently,  this way according to you, may be process P2 run first and then P1, but want P1 first then how it would be possible??

 

 

Yes alan, I had used loops in threads.

[ralph.goergen]

Hi.

 

p1 and p2 run logically in parallel, so you actually don't want to rely on a specific execution order. 

 

You can avoid this situation by not using notify with no parameter (immediate notification). 

Use notify(sc_core::SC_ZERO_TIME) instead to schedule the event in the next delta cycle. 

 

At the end of delty cycle 1, p1 definitely reached the wait instruction and the event in delta cycle 2 triggers p1 to continue. 

 

Greetings

Ralph