Waiting for multiple events

Peter Dufault dufault at hda.com
Tue Nov 29 14:50:25 UTC 2011

On Nov 29, 2011, at 9:18 , Mogens Dybæk Christensen wrote:

> We are about to port code from the RTXC OS to RTEMS. Several modules use a pattern, where a task is waiting for one of several things to happen. Can be timer, semaphore(s) or queue. The current wrapper implementation uses a semaphore _list_ function in RTXC, which has no direct counterpart in RTEMS.
> The wanted function is similar to select(). (WaitForMultipleObjects() on Windows is another example.) The FAQ on the wiki mentions  RTEMS event as a good alternative. 
> So, the solution could be, that a semaphore or queue is signalled, e.g. from interrupt, and a small helper task waiting at that semaphore/queue will translate to an RTEMS event for the appropriate task. Then the task will check the event mask to see who called, and read from the  queue if needed.
> Has anyone done something similar? I am not really happy with the extra helper tasks.  J 
> But they may be necessary if there is no simple way for the interrupt handler to know the receiving task and its local event encoding.

You may need to explain this to me further.  Do you mean you want to avoid a helper task per event that then posts to a single handler task?  Can the single handler task wait at a message queue with small fixed size messages and can the various interrupts post a cookie to that message queue?  The cookie could be a bit mask of some sort, or even be the function that the task should invoke, though you can hide that in the implementation.

See mq_open(), mq_send(), mq_receive(), mq_close().

Peter Dufault
HD Associates, Inc.      Software and System Engineering

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20111129/4c193054/attachment-0001.html>

More information about the users mailing list