[Xenomai] Manual context switch from userspace

[Xenomai] Manual context switch from userspace

[Stratiyenko Roman]

hello,

Can anyone suggest how to solve next problem?

I need to use the context switch (ucontext.h glibc function) in xenomai
task. But the problem is the swapcontext() make a kernel call that switches
system to secondary mode, so I can't achive hard real time.

What can I do to switch context without switch to secondary mode?
Thanks in advance

Best regards,
Roman

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On 10/15/2014 05:42 PM, Stratiyenko Roman wrote:
> hello,
> 
> Can anyone suggest how to solve next problem?
> 
> I need to use the context switch (ucontext.h glibc function) in xenomai
> task. But the problem is the swapcontext() make a kernel call that switches
> system to secondary mode, so I can't achive hard real time.
> 
> What can I do to switch context without switch to secondary mode?

I would understand the need for using context switches if they were not
going through kernel mode, but if they go through kernel mode, there is
absolutely nothing to gain, you can use threads directly, this will have
the same overhead.

Besides, with such context switches you have risks of interrupting
threads at the wrong time, and cause deadlocks.

-- 
                                                                Gilles.

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On 10/15/2014 06:07 PM, Gilles Chanteperdrix wrote:
> On 10/15/2014 05:42 PM, Stratiyenko Roman wrote:
>> hello,
>>
>> Can anyone suggest how to solve next problem?
>>
>> I need to use the context switch (ucontext.h glibc function) in xenomai
>> task. But the problem is the swapcontext() make a kernel call that switches
>> system to secondary mode, so I can't achive hard real time.
>>
>> What can I do to switch context without switch to secondary mode?
> 
> I would understand the need for using context switches if they were not
> going through kernel mode, but if they go through kernel mode, there is
> absolutely nothing to gain, you can use threads directly, this will have
> the same overhead.

>From the documentation:
CONFORMING TO
       SUSv2, POSIX.1-2001.  POSIX.1-2008 removes the specifications of  make‐
       context()  and swapcontext(), citing portability issues, and recommend‐
       ing that applications be rewritten to use POSIX threads instead.

-- 
                                                                Gilles.

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On 10/16/2014 10:49 AM, Stratiyenko Roman wrote:
> Thank you, I will try longjump() instead of context switch.

If longjmp is in fact siglongjmp, then it will make a system call to 
set the signal mask.

The documentation says:
       longjmp()  and  siglongjmp() make programs hard to understand and main‐
       tain.  If possible an alternative should be used.

What is wrong with using plain threads? Did you observe bad 
performances? On what platform?

-- 
                                                                Gilles.

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On 10/16/2014 11:21 AM, Stratiyenko Roman wrote:
> Preamptive threads is very hard to write. I need synchronize many blocks to
> garanty data integrity.
> My program is an automation with many parallel processes that are using
> data of each other.
> So for me the best solution is remove any preemption.

The thing is, with an RTOS, as long as you are not using timers, the
preemption points are those made explicitly by the application.

You could even implement a sort of makecontext/setcontext system with
pthreads where makecontext would make a pthread_create and initialize a
per thread semaphore, and setcontext woult post the destination thread
semaphore and pend on the current thread semaphore. In fact, you can
explicitly switch between threads by using per-thread semaphores.

(please keep the list posted, do not send me private mails).

-- 
                                                                Gilles.

Re: [Xenomai] Manual context switch from userspace

[Stratiyenko Roman]

Thank you for helping. I replaced swapcontext with longjmp. All works good.
No switch to secondary mode.

As about using threads, I do not fully understand how scheduler works.
Maybe after I will get more experience in multithreading, I will do as you
recommend.



2014-10-16 12:29 GMT+03:00 Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org>:

> On 10/16/2014 11:21 AM, Stratiyenko Roman wrote:
> > Preamptive threads is very hard to write. I need synchronize many blocks
> to
> > garanty data integrity.
> > My program is an automation with many parallel processes that are using
> > data of each other.
> > So for me the best solution is remove any preemption.
>
> The thing is, with an RTOS, as long as you are not using timers, the
> preemption points are those made explicitly by the application.
>
> You could even implement a sort of makecontext/setcontext system with
> pthreads where makecontext would make a pthread_create and initialize a
> per thread semaphore, and setcontext woult post the destination thread
> semaphore and pend on the current thread semaphore. In fact, you can
> explicitly switch between threads by using per-thread semaphores.
>
> (please keep the list posted, do not send me private mails).
>
> --
>                                                                 Gilles.
>

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On 10/17/2014 11:04 AM, Stratiyenko Roman wrote:
> Thank you for helping. I replaced swapcontext with longjmp. All works good.
> No switch to secondary mode.
> 
> As about using threads, I do not fully understand how scheduler works.
> Maybe after I will get more experience in multithreading, I will do as you
> recommend.

Well the rule for SCHED_FIFO is quite simple. At any time, the task with
the highest priority which has been ready for the longest time runs.

This means that when a task runs, it will continue running unless it
wakes up a task with higher priority, or relinquishes cpu by manually
scheduling, calling sched_yield, or gets suspended by calling a service
which suspends its caller, such as pthred_cond_wait, sem_wait, or
pthread_mutex_lock. Of course this is assuming that no time base event
can wake-up a task with higher priority. You get that if you do not use
timers, directly, or indirectly through timed services (nanosleep,
pthread_cond_timedwait, mq_timedsend, etc...).

-- 
                                                                Gilles.

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On Fri, Oct 17, 2014 at 12:04:35PM +0300, Stratiyenko Roman wrote:
> Thank you for helping. I replaced swapcontext with longjmp. All works good.
> No switch to secondary mode.
> 
> As about using threads, I do not fully understand how scheduler works.
> Maybe after I will get more experience in multithreading, I will do as you
> recommend.

Well, this comes late, but I have found a library libtask:
http://swtch.com/libtask/

which does a bit what you want to do, exposing a thread-like API.
What may be interesting for you is that they provide replacements of
makecontext and setcontext for OSes which have no native support for
it, and this does not rely on any system call as far as I can tell,
it will not switch to secondary mode. So you can probably use it on
Linux and bypass the glibc versions. Note however that their context
switching code does not switch the FPU registers, this may be a
performance advantage if you do not use the FPU, but it means it
will not work if you want to switch context in the middle of a
computation using FPU registers.

-- 
					    Gilles.

Re: [Xenomai] Manual context switch from userspace

[Stratiyenko Roman]

Thanks a lot, I already found simple solution at:

http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers

So as I guess, compiler knows what registers are in use now, CPU, FPU etc,
so compiler stores the registers into local memory, only then it switch
Program Counter and Stack Pointer register,

I think this way is most fastest way to switch between tasks, compiler save
only those registers that are used in this moment.


2014-10-28 17:34 GMT+02:00 Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org>:

> On Fri, Oct 17, 2014 at 12:04:35PM +0300, Stratiyenko Roman wrote:
> > Thank you for helping. I replaced swapcontext with longjmp. All works
> good.
> > No switch to secondary mode.
> >
> > As about using threads, I do not fully understand how scheduler works.
> > Maybe after I will get more experience in multithreading, I will do as
> you
> > recommend.
>
> Well, this comes late, but I have found a library libtask:
> http://swtch.com/libtask/
>
> which does a bit what you want to do, exposing a thread-like API.
> What may be interesting for you is that they provide replacements of
> makecontext and setcontext for OSes which have no native support for
> it, and this does not rely on any system call as far as I can tell,
> it will not switch to secondary mode. So you can probably use it on
> Linux and bypass the glibc versions. Note however that their context
> switching code does not switch the FPU registers, this may be a
> performance advantage if you do not use the FPU, but it means it
> will not work if you want to switch context in the middle of a
> computation using FPU registers.
>
> --
>                                             Gilles.
>

Re: [Xenomai] Manual context switch from userspace

[Gilles Chanteperdrix]

On Wed, Oct 29, 2014 at 10:51:18AM +0200, Stratiyenko Roman wrote:
> Thanks a lot, I already found simple solution at:
> 
> http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers
> 
> So as I guess, compiler knows what registers are in use now, CPU, FPU etc,
> so compiler stores the registers into local memory, only then it switch
> Program Counter and Stack Pointer register,
> 
> I think this way is most fastest way to switch between tasks, compiler save
> only those registers that are used in this moment.

Indeed, I downloaded the last version of glibc (which is where the
setjmp function is implemented) and it is true that it does not save all
registers, only the callee saved ones (since setjmp is a function
call, it does not have to save the caller saved registers, since the
compiler expects them to be clobbered anyway). Since the FPU
registers are not callee saved, this is not an issue, and the
compiler will save them by itself before the call to setjmp/longjmp.

Something to be careful about though: setjmp seems to save the
signal mask, and use sigprocmask, which could result in a switch to
secondary mode, so it is probably better to use sigsetjmp and pass 0
as second argument.

-- 
					    Gilles.