[Xenomai-help] Using plain old POSIX shm_open with real time threads

[Xenomai-help] Using plain old POSIX shm_open with real time threads

[Richard Cochran]

Dear xenomai people,

I would like to have a shared ram fifo between a normal Linux program
and a xenomai program that uses the POSIX skin. Can I simply use
__raw_shm_open and __raw_mmap in the xenomai thread, or would there be
some penalty or bad side affect on the RT thread?

I see that the documented way for RT/non-RT IPC is the message
pipe. Perhaps you could comment on the pros/cons of using it, compared
with my shared memory idea.

Thanks,

Richard

Re: [Xenomai-help] Using plain old POSIX shm_open with real time threads

[Gilles Chanteperdrix]

On 08/05/2011 03:30 PM, Richard Cochran wrote:
> Dear xenomai people,
> 
> I would like to have a shared ram fifo between a normal Linux program
> and a xenomai program that uses the POSIX skin. Can I simply use
> __raw_shm_open and __raw_mmap in the xenomai thread, or would there be
> some penalty or bad side affect on the RT thread?

Hi Richard,

You can use shm_open/mmap, but leave out xenomai posix skin shared
memories in kernel configuration: in this case, the __real_ variants
will be used. The only interest of the xenomai posix skin shared
memories is that they allow sharing memory between kernel and user.

Now the armv5 details: xenomai posix skin shared memories are uncached.
plain linux shared memories are uncached when using fcse in guaranteed
mode, and cached when using fcse in best effort mode or without fcse,
but will trigger a cache flush when exiting the process where they are
mapped. They are also uncached when mapped twice at two different
addresses by the same process.

> 
> I see that the documented way for RT/non-RT IPC is the message
> pipe. Perhaps you could comment on the pros/cons of using it, compared
> with my shared memory idea.

Shared memories are not really an IPC, since they do not take care of
synchronization as other IPCs will do. However, for a fifo, this looks
sufficient. A fifo without synchronization, however, will only take care
of one producer and one consumer.

-- 
					    Gilles.

Re: [Xenomai-help] Using plain old POSIX shm_open with real time threads

[Philippe Gerum]

On Fri, 2011-08-05 at 15:30 +0200, Richard Cochran wrote:
> Dear xenomai people,
> 
> I would like to have a shared ram fifo between a normal Linux program
> and a xenomai program that uses the POSIX skin. Can I simply use
> __raw_shm_open and __raw_mmap in the xenomai thread, or would there be
> some penalty or bad side affect on the RT thread?
> 
> I see that the documented way for RT/non-RT IPC is the message
> pipe. Perhaps you could comment on the pros/cons of using it, compared
> with my shared memory idea.

It really boils down to whether your use case is compatible with copying
data between peers (amount, frequency etc.) to gain convenient
synchronization and safe access mechanisms, which you would have to
implement with shared memory otherwise.

The recommended RT IPCs since Xenomai 2.5 are available from the
RTDM-based RTIPC driver, which currently provides three different IPCs
under the same umbrella.

This driver exposes a socket interface to userland, and also benefits
from the intra-kernel API of RTDM (i.e. you can send/receive data from
another driver). For more info, examples/rtdm/profiles/ipc and the
doxygen doc are also available.

> 
> Thanks,
> 
> Richard
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Using plain old POSIX shm_open with real time threads

[Richard Cochran]

On Fri, Aug 05, 2011 at 04:05:51PM +0200, Gilles Chanteperdrix wrote:
> 
> Now the armv5 details: xenomai posix skin shared memories are uncached.
> plain linux shared memories are uncached when using fcse in guaranteed
> mode, and cached when using fcse in best effort mode or without fcse,
> but will trigger a cache flush when exiting the process where they are
> mapped. They are also uncached when mapped twice at two different
> addresses by the same process.

Thanks for the very thorough answer!

(Currently, I am working on a PowerPC project, happily ;)

> Shared memories are not really an IPC, since they do not take care of
> synchronization as other IPCs will do. However, for a fifo, this looks
> sufficient. A fifo without synchronization, however, will only take care
> of one producer and one consumer.

Yes, that is what I am doing.

Thanks,

Richard