[Xenomai-core] Antwort: Re: Antwort: Re: Arguments in psos t_start()

[Xenomai-core] Antwort: Re: Antwort: Re: Arguments in psos t_start()

[Markus Osterried]

Hello Gerum,

actually, when the task's user function (the function which is given in
t_start()) is entered, the arguments have been copied to the new context
and are passed by value.
This is true for real pSOS and also for Xenomai.
But in Xenomai it's the trampoline which acts as a wrapper/prolog and is
created and ready to run in a concurrent context, while still holding a
reference to the arguments in the creator's context.
Real pSOS is a blackbox, so I don't no whether there is a moment in time,
where a new concurrent context is running while still holding a pointer to
old context.
But it's the fact, we have sometimes seen problems with Xenomai, when our
pSOS application changes the arguments value after t_start().
We have never seen this in pSOS.
It's worth to mention, I haven't seen this problem with the newest Xenomai
branch (there was some changes in scheduling?).
But I'm not sure the problem is 100% solved, because with older Xenomai we
have sometimes seen the problem and sometimes not. :-(


Markus





                                                                                                                                               
                              Philippe Gerum                                                                                                   
                              <rpm@xenomai.org         An:      Markus Osterried <Markus.Osterried@domain.hid>                                 
                              g>                      Kopie:   xenomai@xenomai.org                                                            
                              Gesendet von:           Blindkopie:                                                                              
                              xenomai-core-bo         Thema:   Re: [Xenomai-core] Antwort: Re:  Arguments in psos t_start()                    
                              unces@domain.hid                                                                                                    
                                                                                                                                               
                                                                                                                                               
                              09.05.2007                                                                                                       
                              09:55                                                                                                            
                              Bitte antworten                                                                                                  
                              an rpm                                                                                                           
                                                                                                                                               
                                                                                                                                               




On Wed, 2007-05-09 at 09:07 +0200, Markus Osterried wrote:
> Hello Gerum,
>
> sorry for not knowing the details. But there is another question.
> Is it okay to move the pointer to the arguments to the newly created
task?
> Isn't it possible that the task which created the new task is
rescheduled?
> The old task could change the value of the argument and because the new
> task only holds a reference to this argument, the new task is also
> affected.
>

Yes, such side-effect would be possible, not necessarily for the
creator, but for the thread calling t_start() though. The worst case
would happen when calling t_start() with args laid into the caller's
stack space, and the caller unwinding the current frame immediately
since it has a higher priority than the started thread.

This boils down to one question: does actually pSOS pass the argument
array by reference, or by value? In the latter case, the current
implementation would be wrong, otherwise, the side-effect would be
admitted.

--
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@domain.hid
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Antwort: Re: Antwort: Re: Arguments in psos t_start()

[Philippe Gerum]

On Wed, 2007-05-09 at 11:57 +0200, Markus Osterried wrote:
> Hello Gerum,
> 
> actually, when the task's user function (the function which is given in
> t_start()) is entered, the arguments have been copied to the new context
> and are passed by value.
> This is true for real pSOS and also for Xenomai.
> But in Xenomai it's the trampoline which acts as a wrapper/prolog and is
> created and ready to run in a concurrent context, while still holding a
> reference to the arguments in the creator's context.
> Real pSOS is a blackbox, so I don't no whether there is a moment in time,
> where a new concurrent context is running while still holding a pointer to
> old context.

To explain how the pSOS skin currently works:

starter task:
	== syscall == t_start(targs[] by reference)
		kernel/skin: receives the genuine "targ" _pointer_, and copies it
unmodified to the new task's trampoline code in user-space + wakes up
the new task so that it really starts execution (i.e. it was locked into
the trampoline code).

new task (in trampoline code):
		==syscall== wait on the start barrier
			kernel/skin: makes caller wait until t_start is issued
		receives "targs" pointer verbatim, copied back by the last syscall,
and dereferences it to pass the 4 long words from the targs array to the
callback entry routine of the new task.

So, the issue that could happen, is the caller of the t_start() function
in user-space returning to its own caller, with "targs" being laid into
the stack space being unwound. _That_ would be a rainy day. The only
issue otherwise, is the caller of t_start() modifying the arguments
before or while the resumed task accesses them, but that would be more
of a reasonable side-effect of passing arguments by reference, that a
bug per se. Except of course, if pSOS does differently, and always
copies the argument array in the t_start() syscall.

> But it's the fact, we have sometimes seen problems with Xenomai, when our
> pSOS application changes the arguments value after t_start().
> We have never seen this in pSOS.
> It's worth to mention, I haven't seen this problem with the newest Xenomai
> branch (there was some changes in scheduling?).
> But I'm not sure the problem is 100% solved, because with older Xenomai we
> have sometimes seen the problem and sometimes not. :-(

Please be specific; which are the "older Xenomai" and "newest Xenomai
branch"? i.e. which stable version number or SVN commit number for the
trunk/?

This said, I definitely fixed a scheduling issue due to
primary/secondary mode switches involved in creating new user-space
tasks which has been committed in v2.3.1 (i.e. a major rework of the
so-called "RPI management", after Thomas sent me a test case to
illustrate the issue). This bug, for sure, could have impacted your
application in the situation I described earlier, regarding t_start
arguments laid into the stack space. But I have not enough details to be
100% this was related to your problem though.

> 
> 
> Markus
> 
> 
> 
> 
> 
>                                                                                                                                                
>                               Philippe Gerum                                                                                                   
>                               <rpm@xenomai.org         An:      Markus Osterried <Markus.Osterried@domain.hid>                                 
>                               g>                      Kopie:   xenomai@xenomai.org                                                            
>                               Gesendet von:           Blindkopie:                                                                              
>                               xenomai-core-bo         Thema:   Re: [Xenomai-core] Antwort: Re:  Arguments in psos t_start()                    
>                               unces@domain.hid                                                                                                    
>                                                                                                                                                
>                                                                                                                                                
>                               09.05.2007                                                                                                       
>                               09:55                                                                                                            
>                               Bitte antworten                                                                                                  
>                               an rpm                                                                                                           
>                                                                                                                                                
>                                                                                                                                                
> 
> 
> 
> 
> On Wed, 2007-05-09 at 09:07 +0200, Markus Osterried wrote:
> > Hello Gerum,
> >
> > sorry for not knowing the details. But there is another question.
> > Is it okay to move the pointer to the arguments to the newly created
> task?
> > Isn't it possible that the task which created the new task is
> rescheduled?
> > The old task could change the value of the argument and because the new
> > task only holds a reference to this argument, the new task is also
> > affected.
> >
> 
> Yes, such side-effect would be possible, not necessarily for the
> creator, but for the thread calling t_start() though. The worst case
> would happen when calling t_start() with args laid into the caller's
> stack space, and the caller unwinding the current frame immediately
> since it has a higher priority than the started thread.
> 
> This boils down to one question: does actually pSOS pass the argument
> array by reference, or by value? In the latter case, the current
> implementation would be wrong, otherwise, the side-effect would be
> admitted.
> 
> --
> Philippe.
> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 
> 
> 
> 
> 
> 
-- 
Philippe.

Re: [Xenomai-core] Antwort: Re: Antwort: Re: Arguments inpsos t_start()

[Thomas Necker (BA/EDD)]

Hi Philippe

> > We have never seen this in pSOS.
> > It's worth to mention, I haven't seen this problem with the newest 
> > Xenomai branch (there was some changes in scheduling?).
> > But I'm not sure the problem is 100% solved, because with older 
> > Xenomai we have sometimes seen the problem and sometimes not. :-(
> 
> Please be specific; which are the "older Xenomai" and "newest 
> Xenomai branch"? i.e. which stable version number or SVN 
> commit number for the trunk/?

We're working on the 2.3.x branch, not trunk. "Older" means SVN revision
2270.
"Newer" is 2426.

Thomas

[Xenomai-core] PPC context switch

[somshekar kadam]

Hi, 

I was understanding the context switch code of
Xenomai-2.3.0 for PPC, I got the point that once it
enters rthal_thread_switch , xnarch_thread_trampoline
function is executed, register 15 holds this address
of this function and register 2 holds the
rthal_thread_trampoline function, 
what I am not able to understand is how does
rthal_thread_switch function is called, 

I understand from rthal_thread_trampoline
xnarch_thread_trampoline is called by jumping to
function using mtlr and in link register has the
address of xnarch_thread_trampoline stored in reg 15
and uses blr to jump to it and executes new thread. 

what I dont understand is how it excutes
rthal_thread_trampoline, may be some pointers on this,
as I am designing the MIPS context switch code for
threads port for xenomai. 

Thanks In advance 
Neelu



      Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php

Re: [Xenomai-core] PPC context switch

[Gilles Chanteperdrix]

somshekar kadam wrote:
 > Hi, 
 > 
 > I was understanding the context switch code of
 > Xenomai-2.3.0 for PPC, I got the point that once it
 > enters rthal_thread_switch , xnarch_thread_trampoline
 > function is executed, register 15 holds this address
 > of this function and register 2 holds the
 > rthal_thread_trampoline function, 
 > what I am not able to understand is how does
 > rthal_thread_switch function is called, 

rthal_thread_switch is called by xnarch_switch_to, which, in turn is
called when the scheduler decides that the task (the newly created one,
in this case) shoudl run.

 > 
 > I understand from rthal_thread_trampoline
 > xnarch_thread_trampoline is called by jumping to
 > function using mtlr and in link register has the
 > address of xnarch_thread_trampoline stored in reg 15
 > and uses blr to jump to it and executes new thread. 
 > 
 > what I dont understand is how it excutes
 > rthal_thread_trampoline, may be some pointers on this,

xnarch_init_thread prepares the stack and registers of the newly created
task so that rthal_thread_switch does the right thing. Perhaps Philippe
or Wolfgang will be able to give more details.


-- 


					    Gilles Chanteperdrix.