Waiting for multiple events

Mogens Dybæk Christensen MogensD.Christensen at man.eu
Tue Nov 29 15:32:41 UTC 2011


Thanks, we were just discussing the same workaround here:

To use a message que, and then let the interrupt handlers or whatever send a short message containing message type and optional data.

:)

That will require manual modification of approx. 25 source files, so it is possible. The original idea was just to replace the OS wrapper, but the footprint seems too different.


From: Peter Dufault [mailto:dufault at hda.com]
Sent: 29. november 2011 15:50
To: Mogens Dybæk Christensen
Cc: rtems-users at rtems.org
Subject: Re: Waiting for multiple events


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.  :)

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/8b8b28ac/attachment.html>


More information about the users mailing list