Consecutive notify of same event

[ArjunMadhudi]

Hi,

 

I have two threads, one thread (thread2) waits on event 'e' and other thread (thread1) notifies event 'e' at different time instances. Please find the below code,

void thread1()
  {
  	for(int i=0;i!=3;i++)
    {
      wait(5,SC_NS);
      e.notify(0,SC_NS);
      e.notify(3,SC_NS);
      e.notify();
      e.notify(3,SC_NS);
      e.notify(4,SC_NS);
            
      std::cout<<"I am called @ "<<sc_time_stamp()<<endl;
    }
  }
  void thread2()
  {
    static int i=1;
    while(1)
    {
  	  wait(e);
      std::cout<<"e"<<i++<<" @ "<<sc_time_stamp()<<std::endl;
    }
  }

As per LRM 5.10.8, I would expect the following output,

I am called @ 5 ns
e1 @ 5 ns
I am called @ 10 ns
e2 @ 10 ns
I am called @ 15 ns
e3 @ 15 ns

But, the actual output you get when you run is,

I am called @ 5 ns
e1 @ 5 ns
e2 @ 8 ns
I am called @ 10 ns
e3 @ 10 ns
e4 @ 13 ns
I am called @ 15 ns
e5 @ 15 ns
e6 @ 18 ns

This appeared bit strange to me and was just curious to know of what caused this behavior. 

Interestingly, this happens only when you position immediate notification in the middle of series of same event notifications. But, if you place the immediate notification at the very end, then the behavior is as per the expected output above. To add, event "e2" was triggered at 8 ns because we have e.notify(3,SC_NS) and e.notify(4,SC_NS) after immediate notify and the earliest time i.e e.notify(3,SC_NS) survived. Had there been e.notify(1,SC_NS), it prints "e2 @ 6ns" and so on. 

Appreciate any help. Thanks. 

[David Black]

This is both well known and well defined in the specification:

1. sc_event only queues a single event for future notification
2. notify immediate cancels the outstanding queued event and "happens" immediately. This is why it is called "immediate".
3. If you attempt to queue non-zero notifications, only notifications nearer to the current time replace old ones. SC_ZERO_TIME can only be superceded by immediate notification.

If you need to queue multiple notifications use the sc_event_queue.

[ArjunMadhudi]

Hi David,

Thanks for the reply. Yes, sc_event_queue is the solution for consecutive notify of same event. But, I intentionally did not use this feature. Not sure, if one would observe this scenario in the real world case, I was just curious to put an immediate notify in the middle of series of notifications and use an sc_event in this case. To provide enough clarity, my question was, when I have a timed notify after the immediate notify, i.e.,

e.notify();
e.notify(3,SC_NS);

  Thread2 would be triggered twice and it would print,

e1 @ 5 ns
e2 @ 8 ns

But if you reverse the order of notify, i.e., have a timed notify first and then immediate notify,

e.notify(3,SC_NS);
e.notify();

It works as expected and thread2 would be triggered once.

Can anyone please explain what goes in background to cause this behaviour. Thanks again.

[Roman Popov]

Quote

Can anyone please explain what goes in background to cause this behaviour. Thanks again.

e.notify(); // immediate notification is executed "immediately" - Thread2 added to set of runnable processes
e.notify(3,SC_NS); // e added to kernel event queue, it will be triggered in 3 ns

 

e.notify(3,SC_NS); // e added to kernel event queue to be triggered in 3 ns
e.notify(); // previous notification canceled, and instead event is notified immediately, Thread2 added to set of runnable processes

 

 

[David Black]

It should also be noted that sc_event::notify (all variants) are not blocking methods. You would have to yield your process to see the effects. Yielding is accomplished in SC_THREAD using the sc_core::wait (all variants) methods.