[En-Nut-Discussion] reliability of message queues

Ralph Mason ralph.mason at telogis.com
Wed Feb 23 18:44:02 CET 2005


The reason I wrote the message que is two fold.

1. I needed to wait on multiple events.  I looked at implementing it and 
thought about it over quite a while but decided that there was no really 
elegant way to do it that keep the core event system simple and fast.  
Basically I didn't think the overhead was worth the few places I needed 
to do it.

2. Message que are a nice way to make some application structures (state 
machines etc)

As for the reliability, I used them extensively in my code. It's running 
on thousands of boxes 24/7.

The really nice thing with them is you can have worker threads waiting 
on them, each que can time one on wait so the worker can do something.  
Other threads can post to a que to ge that worker to do something.  And 
you can broadcast to all workers.  All these things make each worker 
more like an individual application with the message que providing the 
input.

I have never used then from an interrupt handler.

But then of course I would like them.

Ralph

> Ole,
>
> At 12:43 23.02.2005 +0100, you wrote:
>
>> I just thought to do so. Perhaps I'd better write something like a
>> NutEventWaitMultiple(array of event queues).
>>
>> I'd like to have something like this:
>>
>> Start thread
>> do something
>> wait until connect event or error event (e.g. close down)
>> while not error {
>>   wait until data availabe event or error event
>>   do something
>> }
>>
>> Any idea how to implement this? My first thought was to write the above
>> mentioned function. Message queues would do the job too but with a lot
>> of overhead.
>
>
> Another possibility is to use two thread, each
> waiting on the specific event and let them post
> to a third event queue. For sure this creates the
> maximum overhead you can get. :-)
>
> NutEventWaitMultiple() seems to be the best solution.
> Not sure about its implementation. To speak with
> Mathias' voice: Under all circumstances we must avoid
> blowing up any critical sections.
>
> Harald
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>




More information about the En-Nut-Discussion mailing list