| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Do not use a deadline value of zero to indicate a job cancellation. Use
a dedicated scheduler operation for this.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Introduce map/unmap priority scheduler operations to map thread priority
values from/to the user domain to/from the scheduler domain. Use the
map priority operation to validate the thread priority. The EDF
schedulers use this new operation to distinguish between normal
priorities and priorities obtain through a job release.
Update #2173.
Update #2556.
|
| |
|
|
|
| |
By convention, thread priorities must be integers in RTEMS. Smaller
values represent more important threads.
|
|
|
Start with a copy of the Priority SMP scheduler implementation.
Update #2510.
|
