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-0001.html>
More information about the users
mailing list