Enhancement: add method triggered() to class sc_event_queue

[0-issue]

Just like class sc_event has the method triggered(), it would be worth adding triggered() to class sc_event_queue. That would make it possible to write a process body where sensitivity list has both sc_event and sc_event_queue, and a user wishes to find which one triggered. Thanks!

[lmailletcontoz]

Thanks for submitting this. Could you please share a use case including source code to illustrate the need? The Language WG will explore further what could be done.

[0-issue]

@lmailletcontoz Sure, thanks for getting back. This request is a step to make the event interface consistent across sc_event and sc_event_queue. Given this might get considered by the Language WG, first it is worth exploring this question: is there value in making the event interface (i.e the interface of sc_event and sc_event_queue) consistent? Because if it isn't, then there is no value in exploring this further.

From model development perspective, the event interface has two sides: one facing producer of events and consumer of events (and maybe a 3rd for canceling...). The two types that support the event interface are sc_event and sc_event_queue (not sure if there is a 3rd one yet or in the making). While sc_event and sc_event_queue are implemented in a different manner, the way they are used in the models for producing/consuming events is similar. While their interface is similar on producer side, it is dissimilar on consumer and canceler side. From modeling perspective, the difference is artificial and just adds to the tedium.

1. Producer side has notify(...) for both sc_event and sc_event_queue. This side is consistent, and perhaps even suggests that both sc_event and sc_event_queue are a kind of some abstract event type.
2. The consumer side is inconsistent. For sc_event one can directly use methods like triggered(), wait(), next_trigger(), etc. But for sc_event_queue it requires extracting a reference to an event and using it.
3. The cancel side is inconsistent too. For sc_event there is cancel(), for sc_event_queue there is cancel_all(). As the overloads mentioned in lines are not yet implemented, there is no difference in principle from model development perspective between cancel() on sc_event and cancel_all() on sc_event_queue. And even if those overloads were implemented, just plain cancel() without any args could be made to imply cance_all for sc_event_queue.

While I don't know why that interface design choice was made, one can infer what could have gone in the mind of the developers. From modeling perspective sc_event_queue and sc_event are both types of some abstract event facility: one collapses events in time, the other doesn't. From OOP software implementation perspective, sc_event_queue was not seen as a type of sc_event (for the underlying queueing feature). It appears that the interface design decision got based on implementation detail, and it has remained that way. Not sure if the performance penalty of virtual inheritance is the reason they made the choice of not implementing an interface. There is that implementation (performance) detail to explore too if they decide to make the interface consistent, whether to inherit from an abstract base class or not. Afaik, there isn't a downside of maintaining a consistent interface while not using virtual inheritance there. Though I am not sure if I am missing something.

If you think the Language WG would want to explore this issue further, it would make sense to change the title of the issue to something like: "Enhancement: make the event interface design consistent".

[lmailletcontoz]

Thanks for your contribution. The LWG might consider this for a future standard, as this causes an API change.