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
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
