I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?