| Age | Commit message (Collapse) | Author |
|---|
|
Update #3835.
|
|
If the non-preempt mode for threads is supported depends on the
scheduler implementation. Add
_Scheduler_Is_non_preempt_mode_supported() to indicate this.
Update #3876.
|
|
Test for the proper system condition instead of using the
rtems_configuration_is_smp_enabled() workaround.
Update #3876.
|
|
Allocate new thread queue heads during objects information extend. This
removes an error case and the last dependency on the workspace in
_Thread_Initialize().
Update #3835.
|
|
Move thread stack allocation to caller side of _Thread_Initialize().
Update #3835.
|
|
Update #3835.
|
|
Add the Thread_Configuration structure to reduce the parameter count of
_Thread_Initialize(). This makes it easier to add more parameters in
the future. It simplifies the code generation since most architectures
do not have that many registers available for function parameters.
Update #3835.
|
|
Use the stack area to allocate the TLS area.
Update #3835.
|
|
Use the stack area to allocate the FP context. This considerably
simplifies the application configuration since the task count no longer
influences the configured work space size. With this change the stack
space size is overestimated since an FP context for each thread is
accounted. Memory constraint applications can use the stack size for
fine tuning.
Update #3835.
|
|
Update #3835.
|
|
Remove superfluous Thread_Control::Start::stack member.
Update #3835.
|
|
Update #3706
|
|
In case the robust thread dispatch is enabled by the CPU port, then the
interrupt level must not be changed through the task mode.
Update #3000.
|
|
Update #3000.
|
|
Statically allocate the objects information together with the initial
set of objects either via <rtems/confdefs.h>. Provide default object
informations with zero objects via librtemscpu.a. This greatly
simplifies the workspace size estimate. RTEMS applications which do not
use the unlimited objects option are easier to debug since all objects
reside now in statically allocated objects of the right types.
Close #3621.
|
|
Rename Objects_Information::size to Objects_Information::object_size.
Change its type from size_t to uint16_t and move it to reduce the size
of Objects_Information.
Update #3621.
|
|
Add support to temporarily pin a thread to its current processor. This
may be used to access per-processor data structures in critical sections
with enabled thread dispatching, e.g. a pinned thread is allowed to
block.
Update #3508.
|
|
Use Processor_mask instead.
Update #2514.
|
|
Update #3059.
|
|
Update #3059.
|
|
|
|
Add the special thread queue name _Thread_queue_Object_name to mark
thread queues embedded in an object with identifier. Using the special
thread state STATES_THREAD_QUEUE_WITH_IDENTIFIER is not reliable for
this purpose since the thread wait information and thread state are
protected by different SMP locks in separate critical sections. Remove
STATES_THREAD_QUEUE_WITH_IDENTIFIER.
Add and use _Thread_queue_Object_initialize().
Update #2858.
|
|
|
|
Since the FP area pointer is passed by reference in
_CPU_Context_Initialize_fp() the optional FP area adjustment via
_CPU_Context_Fp_start() is superfluous. It is also wrong with respect
to memory management, e.g. pointer passed to _Workspace_Free() may be
not the one returned by _Workspace_Allocate().
Close #1400.
|
|
Update #2811.
|
|
Update #2797.
|
|
Replace Thread_Scheduler_control::control and
Thread_Scheduler_control::own_control with new
Thread_Scheduler_control::home.
Update #2556.
|
|
Update #2556.
|
|
Update #2556.
|
|
Delete Thread_Control::Resource_node.
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.
|
|
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.
|
|
This information turned out to be useless in the last couple of months.
|
|
This helps to detect double insert and extract errors.
|
|
There was a subtile race condition in _Thread_queue_Do_extract_locked().
It must first update the thread wait flags and then restore the default
thread wait state. In the previous implementation this could lead under
rare timing conditions to an ineffective _Thread_Wait_tranquilize()
resulting to a corrupt system state.
Update #2556.
|
|
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.
|
|
|
|
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 _Thread_Change_life_locked() to avoid duplicated code. Avoid Giant
lock in _Thread_Life_action_handler().
Update #2555.
Update #2626.
|
|
Update #2556.
|
|
Remove support for strict order mutexes.
Close #2124.
|
|
We must provide thread queue heads for the thread wait information for
each thread proxy (thread queue heads were introduced by
d7665823b208daefb6855591d808e1f3075cedcb). The thread proxy must be
allocated before the enqueue operation.
|
|
Yields higher performance on SMP systems.
Close #2625.
|
|
Use a red-black tree instead of delta chains.
Close #2344.
Update #2554.
Update #2555.
Close #2606.
|
|
This reduces the code size of the thread initialization.
|
