"events" in systemverilog

CH-17 Event Details
System verilog events are superior to verilog (named) events
@ and -> operators are backward compatible


sv events are two types: persistent and non-persistent (non-persistent events are same as verilog named events)
non-persistent events don't have a state, hence ascertaining them is not possible i.e the statement "if(posedge clock)" is illegal

sv events act as handles to synchronization queues and can be passed as arguments to tasks, dynamically allocated, reclaimed, assigned to one another
persistence of sv events last for the time step in which they are triggered.

A persistent event will unblock all processes that execute wait() either before or at the time same simulation time as the event is triggered
that is not the case with non-persistent events, wait or @ should be executed before the trigger happens ->
if wait (or @) is executed at the same time as the trigger, the process waiting may unblock or not depending on the execution order of these two processes (wait/@ and ->)
this is a race condition and will not happen with persistent events regardless of the order of execution
persistent events are declared as follows
event bit event_identifier; (note the differnce, bit is added)

wait construct is meaningful only when the event is persistent


does $wait_all() require all the events in the arguments be triggered in the same time stamp?
may be not...coz the spec says
any of the specified event may be triggered more than once...triggering an event more than once in a single time step might be possible but a rarity
so assuming the requirement is not in same time step...but get clarification

how good an idea is to use wait_order to check if events happen in order or not ...an assertion on sequence/order...???

if an event is assigned null, the event is ignored i.e processes waiting on that event does not block, they unblock