| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Update #3059.
|
| |
|
|
|
|
|
| |
In SMP configurations, add a red-black tree node to Scheduler_Node to
enable an EDF scheduler implementation.
Update #3056.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Update #2797.
|
| |
|
|
| |
Update #2556.
|
| | |
|
| |
|
|
| |
Remove unused return status.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Use _Scheduler_SMP_Allocate_processor_exact() to prevent unexpected
migrations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Use priority maximum of scheduler instance. This avoids a potential
memory corruption on SMP configurations.
|
|
|
Start with a copy of the Priority SMP scheduler implementation.
Update #2510.
|
