Douglas Niehaus wrote:Sorry, sloppiness on my part while typing quickly, resulting in the terminolgy problem of --- my using the wrong terminology.
(1.1) Will the use of system services (system calls) by RT threads need to be explicitly supported by, perhaps, explicitly making the schedulers of *other* threads also using those system calls aware of that and take it into account to make those other tasks non-preemptible while holding system call related locks.
(1.2) Can Linux SMP ever support this in an acceptable manner since locks associated with systems services are shared across CPU boundaries. THus, I can isolate a set of RT tasks on a CPU easily, and they are well isolated and can run under strict predictability, *until they use a system call that uses a lock*. Then, the system call is an interaction channel with every other thread on the system using the same system call.
This may be a terminology issue, but I think it would be more correct to
say that the lock is the interaction channel, not the system call, and
it is an interaction channel with every other entity on the system using
the same lock. Depending on the specific lock, this could be other
userspace tasks, kernel threads, or even hardware interrupt handlers.
This goes back to your first question of which system services an RTYes. This is true and is also the point I was trying to make. When talking to people about RT over the years I have observed that it is often hard to communicate the full cost of the predictability required for RT tasks
task can use while maintaining schedulability analysis. Unfortunately
this may be a moving target, since the exact answer depends on what
locks are taken in the underlying kernel implementation.
Chris