| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Remove the thread action handler parameter from
_Thread_Action_initialize() and instead set it later in
_Thread_Add_post_switch_action(). This avoids a dependency on the
thread action handler via the thread initialization.
|
| |
|
|
|
|
|
|
| |
This enables external libraries to use thread locks since they are
independent of the actual RTEMS build configuration, e.g. profiling
enabled or disabled.
|
|
|
|
|
|
|
| |
These SMP lock statistics are used for all lock objects that lack a
storage space for the statistics. Examples are lock objects used in
external libraries which are independent of the actual RTEMS build
configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the storage for the thread queue heads to the threads. Each thread
provides a set of thread queue heads allocated from a dedicated memory
pool. In case a thread blocks on a queue, then it lends its heads to
the queue. In case the thread unblocks, then it takes a free set of
threads from the queue. Since a thread can block on at most one queue
this works. This mechanism is used in FreeBSD. The motivation for this
change is to reduce the memory demands of the synchronization objects.
On a 32-bit uni-processor configuration the Thread_queue_Control size is
now 8 bytes, compared to 64 bytes in RTEMS 4.10 (other changes reduced
the size as well).
|
|
|
|
|
|
|
|
|
|
| |
This was obsolete and broken based upon recent time keeping changes.
Thie build option was previously enabled by adding
USE_TICKS_FOR_STATISTICS=1 to the configure command line.
This propagated into the code as preprocessor conditionals
using the __RTEMS_USE_TICKS_FOR_STATISTICS__ conditional.
|