Re: [Xenomai-help] Shared memory between a Xenomai user task and a standard Linux process?

[Bob Feretich <bob.feretich@domain.hid>]

  Thank you for the solution. Using Linux shm shared memory should have 
been obvious. :-[

I was still thinking of Xenomai user tasks as running in a walled of 
environment. I've got to remember that when a rt user task is in 
secondary mode it has full access to Linux facilities.

When my rt user task starts and ends it is in secondary mode. It can 
easily shmat() and shmdt() during these start and end periods.

As Philippe states, I just need to be careful about the synchronization 
method I use. The Linux process must never be able to block the rt task. 
(If the rt task wraps the buffer, we'll just throw away the history data 
until space becomes available and report a "data overrun" on the next 
block written.) As I said before, the buffer should be large enough so 
that never happens anyway.

Yes, I am using the OMAP3 chip so the D-cache is VIPT, therefore shared 
memory operations should not cause cache flushes to prevent aliasing.

Regards,
Bob Feretich

On 8/2/2010 10:56 AM, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> On Mon, 2010-08-02 at 08:01 +0200, Gilles Chanteperdrix wrote:
>>> Due to their limitations on ARM platform (they are uncached on pre-v6
>>> ARMs), RT_HEAP should more be reserved to communications between
>>> user-space tasks and kernel-space tasks on these platforms. For
>>> communications between two user-space processes, using plain Linux
>>> shared memories is recommended.
>>>
>> ARM VIVT caching kills common sense. Note that in the particular case of
>> a rt / non-rt communication, standard shm would imply priority inversion
>> induced by heavyweight synchronization between rt senders and non-rt
>> receivers, so that would not fly that well. This is still possible to
>> use a lockless approach to queue data though. YMMV.
> Well, in fact, with the native API, you have the choice to use cached or
> non-cached heaps. So, if you know the heap will be used only by
> user-space applications, you can keep the heap cached, and forgot what I
> said. And Bob uses an OMAP3 anyway if I am not mistaken, so he has a
> shiny VIPT cache.
>