...
At the most primitive level, a thread can be waiting for a semaphore, a signal, or a message queue (not empty or not full). Then there are higher level level wrappers around these like mutexes, semaphores, poll waits, etc. But under the hood those are the three fundamental wait mechanisms. Any could be used to accomplish what you want.
...
In this case, your waiting task will block on a call to mq_receive() until a messages message is received. It will then wake up and can process the message. In the interrupt handler, it will call mq_send() when an event of interest occurs which will, in turn, wake up the waiting task.
...
If you don't have an architecture that uses message queues, and all of these threads are waiting only for the interrupt event and nothing else, then sigalling signaling semaphores would work fine too. You are basically using semaphores as condition variables in this case so you do have to be careful.
...
sem_setprotocol() is a non-standard NuttX function that should be called immediately after the sem_init(). The effect of this function call is to disable priority inheritance for that specific semaphore. There should then be no priority inheritance operations on this semaphore that is used for signallingsignaling. See Signaling Semaphores and Priority Inheritance for further information.
...
NOTE: There is possibility of improper interactions between the semaphore when I it is used for signaling and priority inheritance. In this case, you should disable priority inheritance on the signaling semaphore using sem_setprotocol(SEM_PRIO_NONE). See the signaling semaphore Wiki Page for further information.
...
The obvious thing that you did not mention is poll(). See http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
. Since you are writing a device driver, support for the poll() method in your driver seems to be the natural solution. See the drivers/ directory for many examples, drivers/pipes/pipe_common.c for one. Each thread could simply wait on poll(); when the event occurs the driver could then wake up the set of waiters. Under
the Under the hood, this is again just a set of sem_post's. But it is also a very standard mechanism.
In your case, the semantics of poll() might have to be bent just a little. You might have the to bend the meaning of some of the event flags since they are all focused on data I/O events.
...