Waiting for multiple events

[Sergei Organov]

Till Straumann <strauman at slac.stanford.edu> writes:

> Note the following (IIRC)
>
>  1) signaling to a posix condvar on which no thread is blocking has no
>      effect. Unlike an event which is left 'pending' when sent to a task
>      that is not yet waiting for it.

Yeah, and that is by design, making condvar stateless, i.e., the state
being separate from condvar allowing for any programmable condition,
while state in event is an internal bit-field.

>
>  2) a posix condvar is accompanied by a mutex which must be locked
>      by the receiver and should be locked by the sender - which is
>      prohibited in an ISR. However, if you only use the condvar for
>      synchronization (and do not care about/use/change the value
>      of the variable itself) then is should be safe to signal w/o locking
>      the mutex. But property 1) may tempt you to use a variable
>      (or the condvar itself) to 'remember' pending interrupts.
>      In this case you must be extremely careful in order to avoid
>      race conditions since you must not lock the mutex in the ISR.

When one wants to wait for something from ISR, she will need to disable
ISR, then check condition, then wait for condvar if condition is not
met, in a loop (he will still need to lock associated mutex that is just
an overhead in this scenario as ISR won't touch it). I suspect that this
will just work as ISRs will be automatically re-enabled once this thread
is put into sleep on condvar and another thread gets control and
re-disabled on return from the wait. Once condition is met, the loop
should be broken and ISRs are to be restored (and mutex unlocked).

Here is pseudo-code that I suspect should just work on current RTEMS:

Waiting thread:

lock(mutex);
disable_isr();
while(!condition_met())
  wait(condvar);
restore_isr();
unlock(mutex);
// ... do your work.


ISR:

set_condition();
broadcast(condvar);
  

To get rid of the mutex for this purpose, an OS should provide a
simplified mutex-less implementation of condvar to be used with ISR lock
instead of mutex (could be used inter-thread as well, with less
overhead). In fact, I think it could be better for the implementation to
utilize spinlock instead of mutex, the spinlock being degenerated to
simple ISR lock on single-CPU (non-SMP) builds.

-- Sergei.