Replacement for Xenomai's Message queues?

Replacement for Xenomai's Message queues?

[M. Koehrer]

Hi all,

I am about to switch an realtime application from Xenomai to the RT_PREEMPTION patch.
Everything works really smooth, however I have one question.
With my Xenomai application I use the message queue which combine transfer (including queuing)
of data with activation of the thread.
In my Xenomai application I use this feature quite frequently. Now, I am not sure how to do an equivalent
with the RT_PREEMPT patch.
(see http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__native__queue.html)
Of course I could use condition variables and a struct or array to hold the data I want to pass with the activation
of a thread. However, using this approach I do not have the queuing (which is some extra effort I could spent...).
Another idea I have: I could use sockets which realize the queuing but the overhead is too high.

Is there any suitable way to implement a message queue like approach using RT_PREEMPT patch?
I am running x86 (Dual/Quad Cores).

Thanks for all answers on this question.

Regards

Mathias



-- 
Mathias Koehrer
mathias_koehrer@arcor.de


Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns für Sie: der neue Arcor.de-Newsletter!
Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.newsletter
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Replacement for Xenomai's Message queues?

[Darren Hart]

M. Koehrer wrote:
> Hi all,
> 
> I am about to switch an realtime application from Xenomai to the RT_PREEMPTION patch.
> Everything works really smooth, however I have one question.
> With my Xenomai application I use the message queue which combine transfer (including queuing)
> of data with activation of the thread.
> In my Xenomai application I use this feature quite frequently. Now, I am not sure how to do an equivalent
> with the RT_PREEMPT patch.
> (see http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__native__queue.html)
> Of course I could use condition variables and a struct or array to hold the data I want to pass with the activation
> of a thread. However, using this approach I do not have the queuing (which is some extra effort I could spent...).
> Another idea I have: I could use sockets which realize the queuing but the overhead is too high.
> 
> Is there any suitable way to implement a message queue like approach using RT_PREEMPT patch?
> I am running x86 (Dual/Quad Cores).

I don't if we have many xenomai experts on this list. It would help to 
understand which aspects of the Xenomai message queue are important to 
you (other than the ability to block on a queue and wake when a message 
is available). For a basic message queueing system with the ability to 
prioritize messages, you can look to the POSIX.4 Message Queues. A 
google search will provide plenty of howto's, and the API appears at 
least similar to what you were using with Xenomai.

I haven't looked, but I don't think Linux supports message driven 
Priority Inheritance 
(http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html#Priority_inheritance_messages).

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

Re: Re: Replacement for Xenomai's Message queues?

[M. Koehrer]

Hi Darren,

thanks for the response.
You are right, I should clarify the needs I have...
I have two real time applications (two processes), each running a few real time threads.
For inter process communication I want to exchange data between the two applications.
For this I want to use two queues - one for direction A->B and one for B->A.
Now I have the situation that one thread in B that handles the A->B queue is waiting for data from A.
Whenever A has the data available, it writes the data into the A->B queue.
Immediately after receiving data from A, B unblocks and computes some answer data that is written
into the B->A queue. 
The time between sending the data in A and getting the data back from B should be as low as possible 
(real time requirements: at max tens of microseconds...).

The functionality of mq_send, mq_receive looks suitable.
However I am not sure if this can fulfil my performance needs...
Perhaps I still have the "Xenomai" thinking which means that only some special API functions are real time capable
all others are not... With the RT_PREEMPT patch this seems to be much easier as I can use all suitable functionality
(or did I miss some important thing here?!?).

Regards

Mathias


> > Hi all,
> > 
> > I am about to switch an realtime application from Xenomai to the
> RT_PREEMPTION patch.
> > Everything works really smooth, however I have one question.
> > With my Xenomai application I use the message queue which combine transfer
> (including queuing)
> > of data with activation of the thread.
> > In my Xenomai application I use this feature quite frequently. Now, I am
> not sure how to do an equivalent
> > with the RT_PREEMPT patch.
> > (see
> http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__native__que
> ue.html)
> > Of course I could use condition variables and a struct or array to hold
> the data I want to pass with the activation
> > of a thread. However, using this approach I do not have the queuing (which
> is some extra effort I could spent...).
> > Another idea I have: I could use sockets which realize the queuing but the
> overhead is too high.
> > 
> > Is there any suitable way to implement a message queue like approach using
> RT_PREEMPT patch?
> > I am running x86 (Dual/Quad Cores).
> 
> I don't if we have many xenomai experts on this list. It would help to 
> understand which aspects of the Xenomai message queue are important to 
> you (other than the ability to block on a queue and wake when a message 
> is available). For a basic message queueing system with the ability to 
> prioritize messages, you can look to the POSIX.4 Message Queues. A 
> google search will provide plenty of howto's, and the API appears at 
> least similar to what you were using with Xenomai.
> 
> I haven't looked, but I don't think Linux supports message driven 
> Priority Inheritance 
> (http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html#Prio
> rity_inheritance_messages).
> 
> -- 


-- 
Mathias Koehrer
mathias_koehrer@arcor.de


Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns für Sie: der neue Arcor.de-Newsletter!
Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.newsletter
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Replacement for Xenomai's Message queues?

[Darren Hart]

M. Koehrer wrote:
> Hi Darren,
> 
> thanks for the response.
> You are right, I should clarify the needs I have...
> I have two real time applications (two processes), each running a few real time threads.
> For inter process communication I want to exchange data between the two applications.
> For this I want to use two queues - one for direction A->B and one for B->A.
> Now I have the situation that one thread in B that handles the A->B queue is waiting for data from A.
> Whenever A has the data available, it writes the data into the A->B queue.
> Immediately after receiving data from A, B unblocks and computes some answer data that is written
> into the B->A queue. 
> The time between sending the data in A and getting the data back from B should be as low as possible 
> (real time requirements: at max tens of microseconds...).
> 
> The functionality of mq_send, mq_receive looks suitable.
> However I am not sure if this can fulfil my performance needs...
> Perhaps I still have the "Xenomai" thinking which means that only some special API functions are real time capable
> all others are not... With the RT_PREEMPT patch this seems to be much easier as I can use all suitable functionality
> (or did I miss some important thing here?!?).

You would need to look into how glibc implements the mq_* functions. If 
there are internal locks that are not PI aware (seems likely) then you 
will have limited RT functionality in that an unbounded priority 
inversion would be possible if you aren't very careful in how you 
program your application. Since I haven't examined these paths myself, I 
can't say if there are other issues with using them in a real-time 
system. If you do dig into this, please share what you find, perhaps 
there is something that can be done to improve these interfaces if they 
do not meet your needs.

There are also commercial messaging middleware products that are aimed 
at meeting your requirements of low latency.

Thanks,

--
Darren Hart


> Regards
> 
> Mathias
> 
> 
>>> Hi all,
>>>
>>> I am about to switch an realtime application from Xenomai to the
>> RT_PREEMPTION patch.
>>> Everything works really smooth, however I have one question.
>>> With my Xenomai application I use the message queue which combine transfer
>> (including queuing)
>>> of data with activation of the thread.
>>> In my Xenomai application I use this feature quite frequently. Now, I am
>> not sure how to do an equivalent
>>> with the RT_PREEMPT patch.
>>> (see
>> http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__native__que
>> ue.html)
>>> Of course I could use condition variables and a struct or array to hold
>> the data I want to pass with the activation
>>> of a thread. However, using this approach I do not have the queuing (which
>> is some extra effort I could spent...).
>>> Another idea I have: I could use sockets which realize the queuing but the
>> overhead is too high.
>>> Is there any suitable way to implement a message queue like approach using
>> RT_PREEMPT patch?
>>> I am running x86 (Dual/Quad Cores).
>> I don't if we have many xenomai experts on this list. It would help to 
>> understand which aspects of the Xenomai message queue are important to 
>> you (other than the ability to block on a queue and wake when a message 
>> is available). For a basic message queueing system with the ability to 
>> prioritize messages, you can look to the POSIX.4 Message Queues. A 
>> google search will provide plenty of howto's, and the API appears at 
>> least similar to what you were using with Xenomai.
>>
>> I haven't looked, but I don't think Linux supports message driven 
>> Priority Inheritance 
>> (http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html#Prio
>> rity_inheritance_messages).
>>
>> -- 
> 
> 


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

Re: Replacement for Xenomai's Message queues?

[Carsten Emde]

Mathias,

> [..] I have two real time applications (two processes), each running 
> a few real time threads. For inter process communication I want to 
> exchange data between the two applications. For this I want to use 
> two queues - one for direction A->B and one for B->A. Now I have the 
> situation that one thread in B that handles the A->B queue is
> waiting for data from A. Whenever A has the data available, it writes
> the data into the A->B queue. Immediately after receiving data from
> A, B unblocks and computes some answer data that is written into the
> B->A queue. The time between sending the data in A and getting the
> data back from B should be as low as possible (real time
> requirements: at max tens of microseconds...).
> 
> The functionality of mq_send, mq_receive looks suitable.
Alternatively, you may consider to use shared memory and to synchronize
and protect accesses to that memory with semaphores. The rt-tests suite
contains several examples of how to do it. Before using these test
programs as template for your own application, you may even run them as
they are to check whether the worst-case latency of such mechanisms fits
your requirements.

	Carsten.

Re: Replacement for Xenomai's Message queues?

[Tim Sander]

Hi Mathias

What about http://www.zeromq.org/? Haven't tested it myself
but if you do give some feedback please.

The even have done some tests with preemt-rt linux. With quite good
results.

Best Regards
Tim