| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The priority affinity scheduler has the nice property that it can
produce more than one scheduled to ready state change in one operation.
Each scheduled to ready state change may lead to one thread in need for
help. Since it is currently only possible to return at most one thread
in need for help, we have a problem here.
A solution might be to move the check for migrations into the ask for
help mechanism.
|
|
|
|
|
| |
Do not extract the idle threads from the ready set so that there is
always a thread available for comparison.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following scheduler operations return a thread in need for help
- unblock,
- change priority, and
- yield.
A thread in need for help is a thread that encounters a scheduler state
change from scheduled to ready or a thread that cannot be scheduled in
an unblock operation. Such a thread can ask threads which depend on
resources owned by this thread for help.
Add a new ask for help scheduler operation. This operation is used by
_Scheduler_Ask_for_help() to help threads in need for help returned by
the operations mentioned above. This operation is also used by
_Scheduler_Thread_change_resource_root() in case the root of a resource
sub-tree changes. A use case is the ownership change of a resource.
In case it is not possible to schedule a thread in need for help, then
the corresponding scheduler node will be placed into the set of ready
scheduler nodes of the scheduler instance. Once a state change from
ready to scheduled happens for this scheduler node it may be used to
schedule the thread in need for help.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Return a thread in need for help for the following scheduler operations
- unblock,
- change priority, and
- yield.
A thread in need for help is a thread that encounters a scheduler state
change from scheduled to ready or a thread that cannot be scheduled in
an unblock operation. Such a thread can ask threads which depend on
resources owned by this thread for help.
|
|
|
|
|
|
| |
This emphasizes that the scheduler node of a thread is returned and this
is not a function working with scheduler nodes like the other *_Node_*()
functions.
|
|
|
|
| |
Avoid copy and paste and set the scheduler node state in one place.
|
|
|
|
|
|
| |
Rename and move _Scheduler_SMP_Update_heir() to
_Thread_Dispatch_update_heir() since this function is not scheduler
specific.
|
|
|
|
|
|
|
| |
Add a chain node to the scheduler node to decouple the thread and
scheduler nodes. It is now possible to enqueue a thread in a thread
wait queue and use its scheduler node at the same for other threads,
e.g. a resouce owner.
|
|
|
|
| |
This helps to avoid untestable code for the normal SMP schedulers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This scheduler attempts to account for needed thread migrations caused
as a side-effect of a thread state, affinity, or priority change operation.
This scheduler has its own allocate_processor handler named
_Scheduler_SMP_Allocate_processor_exact() because
_Scheduler_SMP_Allocate_processor() attempts to prevent an executing
thread from moving off its current CPU without considering affinity.
Without this, the scheduler makes all the right decisions and then
they are discarded at the end.
==Side Effects of Adding This Scheduler==
Added Thread_Control * parameter to Scheduler_SMP_Get_highest_ready type
so methods looking for the highest ready thread can filter by the processor
on which the thread blocking resides. This allows affinity to be considered.
Simple Priority SMP and Priority SMP ignore this parameter.
+ Added get_lowest_scheduled argument to _Scheduler_SMP_Enqueue_ordered().
+ Added allocate_processor argument to the following methods:
- _Scheduler_SMP_Block()
- _Scheduler_SMP_Enqueue_scheduled_ordered()
- _Scheduler_SMP_Enqueue_scheduled_ordered()
+ schedulerprioritysmpimpl.h is a new file with prototypes for methods
which were formerly static in schedulerprioritysmp.c but now need to
be public to be shared with this scheduler.
NOTE:
_Scheduler_SMP_Get_lowest_ready() appears to have a path which would
allow it to return a NULL. Previously, _Scheduler_SMP_Enqueue_ordered()
would have asserted on it. If it cannot return a NULL,
_Scheduler_SMP_Get_lowest_ready() should have an assertions.
|
|
|
|
|
|
|
|
| |
Replace _Scheduler_Allocate() with _Scheduler_Node_initialize(). Remove
the return status and thus the node initialization must be always
successful.
Rename _Scheduler_Free() to _Scheduler_Node_destroy().
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename scheduler per-thread information into scheduler nodes using
Scheduler_Node as the base type. Use inheritance for specialized
schedulers.
Move the scheduler specific states from the thread control block into
the scheduler node structure.
Validate the SMP scheduler node state transitions in case RTEMS_DEBUG is
defined.
|
|
|
|
|
|
|
|
|
|
|
| |
The thread control block contains fields that point to application
configuration dependent memory areas, like the scheduler information,
the API control blocks, the user extension context table, the RTEMS
notepads and the Newlib re-entrancy support. Account for these areas in
the configuration and avoid extra workspace allocations for these areas.
This helps also to avoid heap fragementation and reduces the per thread
memory due to a reduced heap allocation overhead.
|
|
|
|
|
|
| |
Do not allocate the scheduler control structures from the workspace.
This is a preparation step for configuration of clustered/partitioned
schedulers on SMP.
|
|
|
|
|
| |
Scheduler operations must be free of a global scheduler context to
enable partitioned/clustered scheduling.
|
|
|