Philippe Gerum wrote:
> On Sun, 2010-08-01 at 19:06 -0700, Bob Feretich wrote:
>> I understand that a RT_PIPE is the preferred way to move data between
>> a rt user task and a standard Linux process, but I have a large amount
>> of data to move per second and I would like to minimize the number of
>> times that the data is copied.
Ok. I was writing my own answer, but Philippe was faster... So, I will
just add a few things.
>> My rt user task performs several tasks that need to be time
>> deterministic. I also want to store a history of its activity in a
>> standard Linux file. Adequate buffering is available so that the file
>> writing and management does not need to be done in real time.
>>
>> Ideally, I would like to share a block of memory (~128KB) between the rt
>> user task and a standard Linux process which performs the file activities.
>>
>> The documentation indicates that many API calls are available to "user
>> tasks", but I assume that unless "Linux process" is explicitly mentioned
>> (as in the case of "pipe") these references apply only to rt user tasks.
>> Am I correct?
>
> Actually, you have two kinds of Xenomai threads in userland which may
> access any Xenomai service, including blocking ones, and generally
> speaking, any service which requires the caller to be known from the
> Xenomai core:
>
> - common rt threads. Those are assigned a runtime priority > 0 when you
> create them via rt_task_create/rt_task_shadow using the native API
> (1-99); they are mapped on the SCHED_FIFO policy when operating in
> secondary mode.
>
> - non-rt threads, but still Xenomai threads. Those are assigned a zero
> priority value. They are mapped on the SCHED_NORMAL/OTHER policy when
> operating in secondary mode, but still have access to primary mode, just
> like any rt threads does. In primary mode, they do not compete for the
> CPU with Xenomai rt threads though, they are scheduled when no rt
> activity remains. However, because they may enter primary mode, they may
> do whatever a rt Xenomai thread does, like pending on a Xenomai
> synchronization object (RT_SEM, RT_QUEUE, ...), because they are known
> from the Xenomai core (in short: they have a thread control block and a
> scheduling slot there). The only difference is their lower (Xenomai)
> priority.
We also have the "rt_printf" service, from the rtdk header, which allows
an RT task to write to a FILE * from primary mode, without incuring a
switch to secondary mode. But this means a copy of the data.
>
>> Is there a shared memory mechanism that works between a rt user task and
>> a standard Linux process?
>>
>
> RT_HEAP would do. Synchronization could be done between the rt and
> non-rt domains based on RT_SEM/RT_MUTEX, provided the Linux process is
> actually a non-rt Xenomai thread. This said, this would introduce a
> potential for priority inversion, since your non-rt thread could hold
> the critical section for an unbounded amount of time, while the rt
> thread attempts to enter it. Using RT_QUEUEs would avoid this.
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.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
