Re: [RFC] shadow threads with prio 0 / SCHED_NORMAL

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>  > What I suggested was to let people create normal threads using  >
>> pthread_create (likely conforming to the SCHED_OTHER policy), then use
>>  > the redirected pthread_setschedparam syscall (i.e. always applied
>> to the  > current thread) to promote them as Xenomai shadows, but
>> leave them in  > their original scheduling class. The same goes for
>> rt_task_shadow. This  > would be explicit actions that would not leave
>> much room for "surprises".
>>
>> If I understand correctly, you mean that one should not be able to
>> create real-time threads with pthread_create. My question was about what
>> to do of explicit scheduling parameters passed to pthread_create through
>> thread creation attributes.
> 
> Nope, this is obviously not what I meant... :o>
> 
> This is how one would create hybrids, without changing anything else to
> the current interface:
> 
>     pthread_attr_init(&attr);
>     ...
>     pthread_attr_setschedpolicy(&attr,SCHED_OTHER);
>     ...
>     pthread_create(...,&attr,&foo,NULL);
> 
> and,
> 
> void *foo (void *cookie)
> {
>     /* The following call maps a shadow thread to "current", but
>               currently only accepts SCHED_FIFO, and would be changed to
>                                    allow SCHED_OTHER/NORMAL. */
>     pthread_setschedparam(...,SCHED_OTHER,...);
>     /* OR, for the native API */
>     rt_task_shadow(...,pri=0,...);
> }
> 

I think it melts down to the question: which kind of SCHED_OTHER threads
will be more common in applications, the hybrid or the normal ones?
Remember that we also still have the __real_pthread_create interface for
creating /really/ normal threads...

The advantage of making hybrids default, even for the attr=NULL case,
would be that the user will be able to interact with real-time
SCHED_FIFO/RR threads without further coding effort (might be
interesting for porting existing apps...).

How much overhead would default-shadowing introduce when it is not used
actively? Is it just the kernel pthread structure? Maybe we should
consider allocating that structure from normal kernel memory to save
rt-memory resources (under memory pressure, there is a risk in failing
to create the Linux mate anyway). I could also imagine that SCHED_OTHER
threads will get started in relaxed mode by default so that the Xenomai
scheduler will not be additionally loaded.

Jan

signature.asc
Description: OpenPGP digital signature

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