On 02/20/2014 11:09 AM, Leopold Palomo-Avellaneda wrote:
> A Dijous, 20 de febrer de 2014, Gilles Chanteperdrix va escriure:
>> On 02/20/2014 12:41 AM, Leopold Palomo-Avellaneda wrote:
>>> Well,
>>>
>>> please, correct me if I'm wrong in some of this sentences. I
>>> will try to rewrite my email in a more clear terminology.
>>>
>>> Following [1] I understand that a realtime task is scheduled by
>>> the
> Xenomai
>>> scheduler and a non-realtime by the Linux scheduler. I can use
>>> the terms "thread" and "task" in the same meaning.
>>
>> Again: the terms "real-time" and "non real-time" are ambiguous.
>> Please stick to the terms "task with a shadow", "task without a
>> shadow" and "primary mode" or "secondary mode".
>>
> :-(
>
> Ok,
>
> I agree with you that the nomenclature is important to define
> correctly but please don't be so strict.
I'm in the open source world since long time ago,
> and I understand perfectly that the main developers of a projects
> are tired of dummy questions, or not clear mails, etc. But, I think
> that the relatime world is a complex thing, and not so easy when
> you are learning, or having troubles.
>
> And although that there's a lot documentation, it's difficult to
> find the document that fits all your doubts.
>
> So, again, please, correct me if I'm wrong in some of this
> sentences. I will try to rewrite my email in a more clear
> terminology.
>
> Following [1] and [2] I understand that a realtime thread is
> executed in primary mode and scheduled by the Xenomai scheduler.
Listen, there are three cases:
1- thread with a shadow running in primary mode
2- thread with a shadow running in secondary mode
3- thread without a shadow
and you want to use two words "real-time thread" and "non real-time
thread". 1 is obviously a real-time thread, 3 is obviously a
non-real-time thread. What do you make of 2? If you consider "being
real-time" a "static" property, then 2 is a real-time thread. If you
consider it a run-time property, a state of a task, then 2 is a
non-real-time thread.
So, again, depending on what you make of 2, you may be wrong or right.
If 2 is with 1, you are wrong, a real-time thread can be scheduled by
Linux scheduler, it is called secondary mode. If 2 is with 3, you are
right, a real-time thread is always scheduled by Xenomai scheduler.
> If this RT thread call a non-RT primitive, then RT-Nucleus move
> this RT-Thread to the Linux queue and this thread is controlled by
> the Linux scheduler. A Non-RT thread is executed in secondary mode
> and controlled by the Linux scheduler.
If 2 is with 3 (which would make your first assertion right), here you
are wrong. Only a thread with a shadow can run in secondary mode,
there is no primary or secondary mode for threads without a shadow.
>
> What I don't understand is for example, I create a C/C++ program,
> and I use the command rt_task_create, linked against xenomai and
> native, and not use the POSIX skin. This program has its own main
> thread and another thread: the thread of the rt_task. May I
> understand that the main thread of the program is controlled by the
> Linux scheduler and executed in secundary mode and the rt- task is
> controlled by the Xenomai scheduler and executed in primary domain?
> It's true?
The main thread is controlled by the Linux scheduler, and not executed
in secondary mode, since it does not have a shadow.
>
> If I have a program (with main, etc) like the examples, if I call
> the rt_task_shadow, the main thread of the program (or from where I
> call it) turns the current thread, (executed in secondary,
> controlled by the Linux scheduler) and move this thread to primary
> mode and controlled by the Xenomai scheduler?
This is where you mix things up. Again, a task with a shadow can run
either in primary or secondary mode. Just after it has been shadowed,
if it uses a priority greater than 0, it will run in primary mode, if
it uses priority 0, it will run in secondary mode. But its current
mode is dynamic, it will change depending on the services it uses.
>
> In our case, the SOEM rt version has NO threads. Just a bunch of
> functions and a mutex that is changed in the RT version by a
> rt_mutex. The devices are opened and used by rt_*** functions. No
> posix functions.
>
> From my point of view, I should be able to have a Linux (NRT)
> program (executed in secondary mode, Linux scheduler) that open the
> RTNet device (raw mode, rtdm), configure the slaves and then a
> rt_task (executed in primary mode, Xenomai scheduler) that send and
> receive in a deterministic way the devices, while the rest of the
> program (the main thread, or others threads) live happy in the
> (secondary mode, Linux scheduler) world.
Being in primary or secondary mode is a property handled on a service
by service basis. You can very well create the rt_task, get it to call
nrt services for initializations, then run in primary mode after the
initialization phase.
>
> I understand that if a thread that is running in primary mode calls
> any Linux function (non-rt primitive) then there's a context
> change. It's moved from primary mode to secondary mode. But if not,
> in our case just xddp communications, my rt_task should be in the
> RT world, primary mode.
That depends on:
- the priority it uses (remember priority 0 means that the task will
try hard to remain in secondary mode);
- the last service it called (if the last service was a real-time
service, then the task switched to primary mode)
- whether you run inside gdb (gdb uses signals, which causes tasks to
switch to secondary mode);
- whether your task caused a trap, because of a page fault for
instance (traps cause tasks to switch to secondary mode).
>
> Our aim is to design NRT master and slaves (c++ objects) that
> communicates with a RT task. The RT task is in charge of establish
> a continuous communication with EtherCAT devices. This task
> communicates with NRT master by the xddp sockects. The problem
> appears when the master call the RT SOEM functions for the
> configuration, because it is necessary that the master becomes a RT
> task, if not it doesn't work. And it has no sense.
Only a task with a shadow can call RT services, because it needs to be
able to switch to primary mode, and only a task with a shadow can
switch to primary mode.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
