On Mon, 2010-08-02 at 08:01 +0200, Gilles Chanteperdrix wrote: > 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. >
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. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
