j-breeze,
The NotifyDriverCirc is a bit different from NotifyDriverShm in this regard.
Note: the code from your previous post relates to event registration.
With NotifyDriverShm, each eventId has its own event flag. If you call Notify_sendEvent() back-to-back with the same eventId, and the previous event has not yet been processed, then waitClear=TRUE will cause the second invocation to busy wait. However, if you call Notify_sendEvent() with two different eventIds, and the first eventId has not yet been processes, the second call will not busy wait (assuming that it's event flag is clear). In other words, you will only busy wait if the current eventId you are sending has a previous outstanding event which has not yet been processed.
You can see this in NotifyDriverShm.c: NotifyDriverShm_sendEvent(). Look for the following while statement:
/* Wait for completion of previous event from other side. */
while ((eventEntry->flag != NotifyDriverShm_DOWN)) {
With NotifyDriverCirc, the implementation uses a queue object to transfer the eventId and payload from the local processor to the remote processor. There is no event flag at all. Each time you call Notify_sendEvent(), the eventId and payload are added to the queue. Some time later, the remote processor will remove the eventId and payload from the queue and process the event. This means that you could call Notify_sendEvent() back-to-back with the same eventId, and even if the first event is still in the queue (i.e. it has not yet been processed), the second call will not busy wait. It will simply add the second event to the queue. However, the outcome should be the same. The remote processor will process the first event before processing the second event.
But, if you application is using waitClear as a means to synchronize, then it will be different. If you application expects to busy wait until the first event has been processed, then using NotifyDriverCirc will not be correct. Your application might think that after sending the second event, the previous event has already been processed, but this might not be the case.
With NotifyDriverCirc, the waitClear flag is used to busy wait when the queue is full. But there is not way to identify which events are in the queue. We use one queue for all events. If we had used a separate queue for each event, then it would have been different.
You can see this in NotifyDriverCirc.c: NotifyDriverCirc_sendEvent(). Look for the following if-statement:
/* check to make sure code has looped */
if (loop && !waitClear) {
/* if no slot available and waitClear is 'FALSE' */
return (Notify_E_FAIL);
}
The primary use for waitClear is not for synchronization, but to ensure that the payload is not lost.
~Ramsey