isaac.gutekunst at vecna.com
Fri Feb 12 18:41:10 UTC 2016
That's exactly my use case. I never actually went and tested that they
blocked, just anticipated this would be a problem later, as I was using
the queue as a mechanism to limit memory allocations.
This is actually for some application data tracing/logging and I didn't
want the log statements to hold up other tasks.
Thanks for the help!
On 02/12/2016 11:10 AM, Joel Sherrill wrote:
> On Fri, Feb 12, 2016 at 9:40 AM, Isaac Gutekunst
> <isaac.gutekunst at vecna.com <mailto:isaac.gutekunst at vecna.com>> wrote:
> Hi All,
> I have an application where having a non-blocking
> rtems_message_queue_send would be useful.
> I will have multiple producers and a single consumer task wise, so
> using rtems_message_queue_get_number_pending as method to determine
> if the next send will succeed won't work.
> Has anyone had a similar problem before?
> I'm thinking I can wrap all calls to this message queue with a
> counting semaphore and use that to arbitrate. Any other suggestions?
> rtems_message_queue_send() does not block at all. Either the message can
> be enqueued or you get a message queue full error.
> POSIX message queues can optionally block on the mq_send() but not
> Classic API message queues.
> Am I missing your use case? Or did you misinterpret something?
> users mailing list
> users at rtems.org <mailto:users at rtems.org>
More information about the users