[Xenomai-help] pthread creation with native api

[Xenomai-help] pthread creation with native api

[Enric Bel Prim]

Hi,
I have some questions regarding pthread and NATIVE API...

I use xenomai 2.4.8 with native API and RTDM services in a linux 2.6.28
lite5200 embedded platform.
My application creates several realtime tasks (rt_task) using native
api, inside a linux environment with other applications.  All worked
fine, till I need to create, from any of this rt_task, some nonrealtime
tasks to do a long and not priority jobs (parse huge xml files, compress
/ uncompress them...).
To do that, I use pthread_create(), to create a non realtime task with
the "default attributes".
I expected that this pthread would share the remaining CPU time with the
other linux applications.   
But it seems that this new pthread created has higher priority than any
of the other non-RT linux apps.  The feeling is that the CPU is shared
only between the realtime tasks and this pthread: for instance, one of
the other non-RT apps controls the watchdog, and it resets the system
some seconds after the pthread is created.
If I call pthread_getschedparam inside the pthread I get thread prio =
0, and SCHED_OTHER.
I tried using __real_pthread_create as well, and had the same result.

Is correct to use pthread_create to create a new non-RT task from a
rt_task?
Which are the attributes/priority of that pthread? Does it inherit some
of the RT parent "privileges"?

Thanks,
Enric. 
 
----------------------------------------- PLEASE NOTE -------------------------------------------
This message, along with any attachments, may be confidential or legally privileged. 
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses contained in any attachment.
 
------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal. 
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.  
ZIV utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.

Re: [Xenomai-help] pthread creation with native api

[Gilles Chanteperdrix]

On 11/22/2011 09:51 AM, Enric Bel Prim wrote:
> Hi,
> I have some questions regarding pthread and NATIVE API...
> 
> I use xenomai 2.4.8 with native API and RTDM services in a linux 2.6.28
> lite5200 embedded platform.
> My application creates several realtime tasks (rt_task) using native
> api, inside a linux environment with other applications.  All worked
> fine, till I need to create, from any of this rt_task, some nonrealtime
> tasks to do a long and not priority jobs (parse huge xml files, compress
> / uncompress them...).
> To do that, I use pthread_create(), to create a non realtime task with
> the "default attributes".
> I expected that this pthread would share the remaining CPU time with the
> other linux applications.   
> But it seems that this new pthread created has higher priority than any
> of the other non-RT linux apps.  The feeling is that the CPU is shared
> only between the realtime tasks and this pthread: for instance, one of
> the other non-RT apps controls the watchdog, and it resets the system
> some seconds after the pthread is created.
> If I call pthread_getschedparam inside the pthread I get thread prio =
> 0, and SCHED_OTHER.

Up to here, it makes sense if you are passing flags to compile for the
posix skin.

> I tried using __real_pthread_create as well, and had the same result.

This does not make sense.

> 
> Is correct to use pthread_create to create a new non-RT task from a
> rt_task?
> Which are the attributes/priority of that pthread? Does it inherit some
> of the RT parent "privileges"?

When compiling for the posix skin, threads created with pthread_create
are the same kind of tasks as the ones created with rt_task_create. The
SCHED_OTHER/0 priority is simply the lowest priority for these tasks. If
you do not want that, you should not pass the flags to compile for the
posix skin.

However, even when using the posix skin compilation flags, this should
not happen when using __real_pthread_create. Could you try xenomai
2.4.10 and see if it has the same behaviour?

Could you post an example program?

-- 
					    Gilles.

Re: [Xenomai-help] pthread creation with native api

[Enric Bel Prim]

On 11/22/2011 09:51 AM, Enric Bel Prim wrote:
>> Hi,
>> I have some questions regarding pthread and NATIVE API...
>> 
>> I use xenomai 2.4.8 with native API and RTDM services in a linux 
>> 2.6.28 lite5200 embedded platform.
>> My application creates several realtime tasks (rt_task) using native 
>> api, inside a linux environment with other applications.  All worked 
>> fine, till I need to create, from any of this rt_task, some 
>> nonrealtime tasks to do a long and not priority jobs (parse huge xml 
>> files, compress / uncompress them...).
>> To do that, I use pthread_create(), to create a non realtime task
with 
>> the "default attributes".
>> I expected that this pthread would share the remaining CPU time with
the
>> other linux applications.   
>> But it seems that this new pthread created has higher priority than 
>> any of the other non-RT linux apps.  The feeling is that the CPU is 
>> shared only between the realtime tasks and this pthread: for
instance, 
>> one of the other non-RT apps controls the watchdog, and it resets the

>> system some seconds after the pthread is created.
>> If I call pthread_getschedparam inside the pthread I get thread prio
= 
>> 0, and SCHED_OTHER.

>Up to here, it makes sense if you are passing flags to compile for the
posix skin.

I agree. The point is that I have not activated the POSIX API, as you
can see...

# Adeos-ipipe
LINUX_CONFIG+=CONFIG_IPIPE=y

# Xenomai
LINUX_CONFIG+=CONFIG_XENOMAI=y

# Nucleus 
LINUX_CONFIG+=CONFIG_XENO_OPT_NUCLEUS=y

LINUX_CONFIG+=CONFIG_XENO_OPT_PIPE=y
LINUX_CONFIG+=CONFIG_XENO_OPT_REGISTRY=y

# Pervasive real-time support in user-space
LINUX_CONFIG+=CONFIG_XENO_OPT_PERVASIVE=y

# Interrupt shield support
LINUX_CONFIG+=CONFIG_XENO_OPT_ISHIELD=i

# Priority shield support 
LINUX_CONFIG+=CONFIG_XENO_OPT_PRIOCPL=i

# Optimize as pipeline head
LINUX_CONFIG+=CONFIG_XENO_OPT_PIPELINE_HEAD=y

# Number of pipe devices
LINUX_CONFIG+=CONFIG_XENO_OPT_PIPE_NRDEV=32

# Number of registry slots
LINUX_CONFIG+=CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512

# Size of the system head (Kb)
LINUX_CONFIG+=CONFIG_XENO_OPT_SYS_HEAPSZ=128

# Size of the private stack pool (Kb)
LINUX_CONFIG+=CONFIG_XENO_OPT_SYS_STACKPOOLSZ=64

# Statistics collection
LINUX_CONFIG+=CONFIG_XENO_OPT_STATS=y

# Debug support
LINUX_CONFIG+=CONFIG_XENO_OPT_DEBUG=i 

# Shared interrupts
LINUX_CONFIG+=CONFIG_XENO_OPT_SHIRQ=y 

# Enable periodic timing
LINUX_CONFIG+=CONFIG_XENO_OPT_TIMING_PERIODIC=i

# Scheduling latency (ns)
LINUX_CONFIG+=CONFIG_XENO_OPT_TIMING_SCHEDLAT=0

# O(1) scheduler
LINUX_CONFIG+=CONFIG_XENO_OPT_SCALABLE_SCHED=i

# Timer indexing method
LINUX_CONFIG+=CONFIG_XENO_OPT_TIMER_LIST=y
LINUX_CONFIG+=CONFIG_XENO_OPT_TIMER_HEAP=i
LINUX_CONFIG+=CONFIG_XENO_OPT_TIMER_WHEEL=i 

# Enable NMI watchdog 
LINUX_CONFIG+=CONFIG_XENO_HW_NMI_DEBUG_LATENCY=i

# Native API
LINUX_CONFIG+=CONFIG_XENO_SKIN_NATIVE=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_PIPE=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_SEM=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_EVENT=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_MUTEX=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_COND=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_QUEUE=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_HEAP=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_ALARM=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_MPS=y
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_INTR=i 
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_PERIOD=0
LINUX_CONFIG+=CONFIG_XENO_OPT_NATIVE_REGISTRY=y

# POSIX API
LINUX_CONFIG+=CONFIG_XENO_SKIN_POSIX=i 

# pSOS+ emulator
LINUX_CONFIG+=CONFIG_XENO_SKIN_PSOS=i 

# uITRON API
LINUX_CONFIG+=CONFIG_XENO_SKIN_UITRON=i 

# VRTX emulator
LINUX_CONFIG+=CONFIG_XENO_SKIN_VRTX=i 

# VxWorks emulator
LINUX_CONFIG+=CONFIG_XENO_SKIN_VXWORKS=i 

# RTAI emulator
LINUX_CONFIG+=CONFIG_XENO_SKIN_RTAI=i 

# Real-Time Driver Model (RTDM)
LINUX_CONFIG+=CONFIG_XENO_SKIN_RTDM=y
LINUX_CONFIG+=CONFIG_XENO_OPT_RTDM_FILDES=128
LINUX_CONFIG+=CONFIG_XENO_OPT_RTDM_SELECT=i 
LINUX_CONFIG+=CONFIG_XENO_OPT_RTDM_PERIOD=0

# Serial drivers
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_16550A=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_16550A_PIO=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_16550A_MMIO=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_16550A_ANY=i 

# CAN drivers
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_DEBUG=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_LOOPBACK=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_MAX_DEVICES=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_MAX_RECEIVERS=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_BUS_ERR=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_CAN_VIRT=i 

# Testing drivers
LINUX_CONFIG+=CONFIG_XENO_KLATENCY_MODULE=i
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_TIMERBENCH=i
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_KLATENCY=i
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_IRQBENCH=i 
LINUX_CONFIG+=CONFIG_XENO_DRIVERS_SWITCHTEST=i

# Enable FPU support 
LINUX_CONFIG+=CONFIG_XENO_HW_FPU=y

# SMI workaround
LINUX_CONFIG+=CONFIG_XENO_HW_SMI_DETECT_DISABLE=i
LINUX_CONFIG+=CONFIG_XENO_HW_SMI_WORKAROUND=i



>> I tried using __real_pthread_create as well, and had the same result.

>This does not make sense.

If POSIX api is not active, __real_pthread_create behaves identically as
pthread_create, I suppose.

>> 
>> Is correct to use pthread_create to create a new non-RT task from a 
>> rt_task?
>> Which are the attributes/priority of that pthread? Does it inherit 
>> some of the RT parent "privileges"?

>When compiling for the posix skin, threads created with pthread_create
are the same kind of tasks as the ones created with rt_task_create. The
SCHED_OTHER/0 priority is simply the lowest priority for these tasks. If
you do not want that, you should not pass the flags to compile for the
posix skin.

I agree. I don't activate posix skin.

>However, even when using the posix skin compilation flags, this should
not happen when using __real_pthread_create. Could you try xenomai
2.4.10 and see if it has the same behaviour?

>Could you post an example program?

>-- 
>					    Gilles.


I tried with version 2.4.10 and I got the same result.  I agree with you
that this should not occur without posix skin compilation flags. I
workaround the problem reducing the pthread priority calling nice() at
the start of pthread code.  But I'd like to know the reason of that
behaviour.

Thanks for your help,
Enric. 
 
----------------------------------------- PLEASE NOTE -------------------------------------------
This message, along with any attachments, may be confidential or legally privileged. 
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses contained in any attachment.
 
------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal. 
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.  
ZIV utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.