| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Ensure that the thread processor affinity fits the new scheduler
instance.
Update #3059.
|
|
|
|
| |
Update #3059.
|
|
|
|
|
|
|
|
| |
The set of online processors must be a subset of the thread processor
affinity for the schedulers without arbitrary processor affinity support
to avoid problems in case of processor addition and removal.
Update #3059.
|
|
|
|
| |
Update #3059.
|
|
|
|
|
|
|
| |
Replace the simple processor count with the processor set owned by the
scheduler instance.
Update #3059.
|
|
|
|
| |
Update #3059.
|
|
|
|
|
|
|
|
|
| |
Check that no ask help request is registered during unblock and yield
scheduler operations. There is no need to ask for help if a scheduled
thread yields, since this is already covered by the pre-emption
detection.
Update #2556.
|
|
|
|
|
|
|
|
|
|
|
| |
Only register ask for help requests in the scheduler unblock and yield
operations. The actual ask for help operation is carried out during
_Thread_Do_dispatch() on a processor related to the thread. This yields
a better separation of scheduler instances. A thread of one scheduler
instance should not be forced to carry out too much work for threads on
other scheduler instances.
Update #2556.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Rename _Scheduler_Assignments into _Scheduler_Initial_assignments to
make it clear that they may not reflect the run-time scheduler
assignment.
Update #2797.
|
|
|
|
|
|
|
| |
This makes it possible to adjust the scheduler of a processor at
run-time.
Update #2797.
|
|
|
|
|
|
|
|
|
|
| |
Avoid dead code in non-SMP configurations. Return scheduler identifier
independent of the current processor count of the scheduler via
rtems_scheduler_ident(), since this value may change during run-time.
Check the processor count in _Scheduler_Set() under scheduler lock
protection.
Update #2797.
|
|
|
|
|
| |
In case the thread is scheduled and the sticky level is greater than
one, then we must use an idle thread for correctness of MrsP.
|
| |
|
|
|
|
|
|
| |
No longer unconditionally prevent scheduler changes if the thread owns
resources. Prevent a scheduler change only in case other threads wait
for the resource.
|
|
|
|
| |
Update #2556.
|
|
|
|
|
|
|
|
| |
Replace Thread_Scheduler_control::control and
Thread_Scheduler_control::own_control with new
Thread_Scheduler_control::home.
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
| |
|
|
|
|
|
|
| |
Delete Thread_Control::Resource_node.
Update #2556.
|
|
|
|
|
|
|
| |
Delete _Scheduler_Thread_change_resource_root() and
_Scheduler_Thread_change_help_state().
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
|
|
|
| |
Add the ability to add/remove scheduler nodes to/from the set of
scheduler nodes available to the schedulers for a particular thread.
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
|
|
| |
Changed for consistency with other scheduler operations.
Update #2556.
|
|
|
|
|
|
| |
Changed for consistency with other scheduler operations.
Update #2556.
|
|
|
|
|
|
| |
Changed for consistency with other scheduler operations.
Update #2556.
|
|
|
|
|
|
|
| |
This enables to call this scheduler operation for all scheduler nodes
available to a thread.
Update #2556.
|
|
|
|
|
|
|
|
| |
Rename the scheduler ask for help stuff since this will be replaced step
by step with a second generation of the scheduler helping protocol.
Keep the old one for now in parallel to reduce the patch set sizes.
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add priority nodes which contribute to the overall thread priority.
The actual priority of a thread is now an aggregation of priority nodes.
The thread priority aggregation for the home scheduler instance of a
thread consists of at least one priority node, which is normally the
real priority of the thread. The locking protocols (e.g. priority
ceiling and priority inheritance), rate-monotonic period objects and the
POSIX sporadic server add, change and remove priority nodes.
A thread changes its priority now immediately, e.g. priority changes are
not deferred until the thread releases its last resource.
Replace the _Thread_Change_priority() function with
* _Thread_Priority_perform_actions(),
* _Thread_Priority_add(),
* _Thread_Priority_remove(),
* _Thread_Priority_change(), and
* _Thread_Priority_update().
Update #2412.
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
|
|
|
|
| |
Split up the potential thread priority change in the scheduler
release/cancel job operation. Protect the rate monotonic period state
with a dedicated SMP lock. This avoids a race condition during
_Rate_monotonic_Timeout() while _Rate_monotonic_Cancel() is called on
another processor.
|
|
|
|
|
| |
Do not use a deadline value of zero to indicate a job cancellation. Use
a dedicated scheduler operation for this.
|
|
|
|
|
|
|
|
|
| |
The _Thread_Lock_acquire() function had a potentially infinite run-time
due to the lack of fairness at atomic operations level.
Update #2412.
Update #2556.
Update #2765.
|
|
|
|
|
|
| |
Provide the scheduler node to initialize or destroy to the corresponding
operations. This makes it possible to have more than one scheduler node
per thread.
|
|
|
|
|
|
|
|
|
|
|
| |
Task priorities are only valid within a scheduler instance. The
rtems_task_set_scheduler() directive moves a task from one scheduler
instance to another using the current priority of the thread. However,
the current task priority of the source scheduler instance is undefined
in the target scheduler instance. Add a third parameter to specify the
priority.
Close #2749.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The thread priority is manifest in two independent areas. One area is
the user visible thread priority along with a potential thread queue.
The other is the scheduler. Currently, a thread priority update via
_Thread_Change_priority() first updates the user visble thread priority
and the thread queue, then the scheduler is notified if necessary. The
priority is passed to the scheduler via a local variable. A generation
counter ensures that the scheduler discards out-of-date priorities.
This use of a local variable ties the update in these two areas close
together. For later enhancements and the OMIP locking protocol
implementation we need more flexibility. Add a thread priority
information block to Scheduler_Node and synchronize priority value
updates via a sequence lock on SMP configurations.
Update #2556.
|
|
|
|
|
|
| |
Pass the deadline in watchdog ticks to the scheduler.
Update #2173.
|