Jan Kiszka wrote:
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:
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. */
/* OR, for the native API */
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...).
That's POSIX centric and seems acceptable, but the question remains open
for the native API. Passing a null priority to rt_task_create would be
way too confusing (i.e. a priority value should be an attribute of the
scheduling class, not the other way around), hence the use of
rt_task_shadow for this particular purpose.
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).
Memory is not an issue anyway, since we need a full shadow TCB to allow
the underlying thread to wait for sync objects, and generally speaking,
to use the RT infrastructure to its full extent. IOW, there is nothing
to save here, an hybrid thread would just be a regular Xenomai shadow
that _only_ happens to undergo the SCHED_OTHER policy.
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.
Yes, we could do that. But in any case, an hybrid would be allowed to
switch to primary for the purpose of pending on synchronization objects,
which in turn would give hybrids a higher priority than regular Linux
SCHED_FIFO threads (i.e. threads not mapped to a Xenomai shadow) in this
Xenomai-core mailing list