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
-----------------
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.html>


More information about the users mailing list