[Xenomai-help] pthread_attr_setfp_np needed in user space apps ?

[Xenomai-help] pthread_attr_setfp_np needed in user space apps ?

[Ulrich Schwab]

Hello,

I am in the progress of porting an application from RTLinux to Xenomai-2.0
While compiling for a user space RT program with the posix skin I get
the following warning:

warning: implicit declaration of function `pthread_attr_setfp_np'

is this call NOT needed in an user space app   ?

It is there in the sources, but does not seem to be exported to a user space 
RT app.

Another point unclear to me is, how are printf's handled in RT user space 
apps ?
Isn't the RT scheduling affected, when done in a RT critical context ?

Thanks, for any comments,
Ulrich Schwab

-- 
====================================================
  inmess GmbH
  Frankfurter Str. 74
  D - 64521 Gross-Gerau
  Phone: +49 6152 97790
  Fax  : +49 6152 977920
  mail : info@domain.hid
  web:   www.inmess.de
====================================================

Re: [Xenomai-help] pthread_attr_setfp_np needed in user space apps ?

[Philippe Gerum]

Ulrich Schwab wrote:
> Hello,
> 
> I am in the progress of porting an application from RTLinux to Xenomai-2.0
> While compiling for a user space RT program with the posix skin I get
> the following warning:
> 
> warning: implicit declaration of function `pthread_attr_setfp_np'
> 
> is this call NOT needed in an user space app   ?
> 

It's not needed. If you selected FPU support in the "Machine" menu when 
configuring, then Xenomai will handle FPU switches properly.

> It is there in the sources, but does not seem to be exported to a user space 
> RT app.
> 
> Another point unclear to me is, how are printf's handled in RT user space 
> apps ?
> Isn't the RT scheduling affected, when done in a RT critical context ?
> 

Printf ends up calling the write(2) system call, which is indeed the issue.
When issuing a Linux call over a RT context, your thread automatically switches 
from primary execution mode (Xenomai) to secondary (Linux). The priority of this 
thread is kept across such migration (*), so the scheduling per se is not 
impacted. What's impacted is the overall determinism one could expect from 
running Linux code, which cannot be guaranteed with vanilla kernels: IOW, you 
would have unpredictable execution times in such context, since nothing could 
guarantee that the syscall some routine end up calling would not be delayed for 
an unbounded amount of time by lower priority kernel operations.

What Xenomai brings is the ability to keep the priority scheme intact in such 
circumstances, so that a high RT priority thread switching in secondary mode is 
still runnable before a low RT priority one. The day we have a really 
deterministic Linux kernel, this little thing will make a huge difference when 
it comes to provide a seamless RT service integration.

> Thanks, for any comments,
> Ulrich Schwab
> 


-- 

Philippe.