| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Rename struct Scheduler_Control to _Scheduler_Control to allow its use
in standard header files, e.g. <pthread.h>.
Update #3112.
|
|
|
|
|
| |
Move _Thread_Scheduler_ask_for_help(), rename it to
_Thread_Ask_for_help() and make it static.
|
|
|
|
|
|
| |
Add configuration option CONFIGURE_MAXIMUM_THREAD_NAME_SIZE.
Update #2858.
|
|
|
|
| |
Update #2858.
|
|
|
|
|
|
|
|
| |
Initialize thread queue context early preferably outside the critical
section.
Remove implicit _Thread_queue_Context_initialize() from
_Thread_Wait_acquire().
|
|
|
|
|
|
|
| |
Replace the expected thread dispatch disable level with a thread queue
enqueue callout. This enables the use of _Thread_Dispatch_direct() in
the thread queue enqueue procedure. This avoids impossible exection
paths, e.g. Per_CPU_Control::dispatch_necessary is always true.
|
|
|
|
|
| |
Maintain the thread resource count only in debug configurations. This
is a performance optimization for non-debug configurations.
|
|
|
|
|
| |
This makes it easier to conditionally enable/disable the thread resource
count usage.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
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.
|
|
|
|
| |
Update #2423.
|
|
|
|
|
|
|
|
| |
Maintain the priority of a thread for each scheduler instance via the
thread queue enqueue, extract, priority actions and surrender
operations. This replaces the primitive priority boosting.
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.
|
|
|
|
| |
Avoid direct access to thread internal data fields.
|
|
|
|
| |
Update #2556.
|
|
|
|
| |
Update #2556.
|
|
|
|
|
|
| |
Introduce Thread_queue_Lock_context to contain the context necessary for
thread queue lock and thread wait lock acquire/release operations to
reduce the Thread_Control size.
|
| |
|
|
|
|
| |
This information turned out to be useless in the last couple of months.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Move the priority change due to priority interitance to the thread queue
enqueue operation to simplify the locking on SMP configurations.
Update #2412.
Update #2556.
Update #2765.
|
|
|
|
|
|
| |
Update #2412.
Update #2556.
Update #2765.
|
| |
|
|
|
|
|
|
|
|
|
| |
Clock disciplines may be WATCHDOG_RELATIVE, WATCHDOG_ABSOLUTE,
or WATCHDOG_NO_TIMEOUT. A discipline of WATCHDOG_RELATIVE with
a timeout of WATCHDOG_NO_TIMEOUT is equivalent to a discipline
of WATCHDOG_NO_TIMEOUT.
updates #2732
|
| |
|
|
|
|
|
| |
The use of atomic fences is brittle and may break due to changes in
different areas which is hard to manage.
|
| |
|
|
|
|
|
|
|
|
| |
According to the C11 standard only atomic read-modify-write operations
guarantee that the last value written in modification order is read, see
"7.17.3 Order and consistency". Thus we must use a read-modify-write in
_SMP_Inter_processor_interrupt_handler() to make sure we read an
up-to-date message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
The approach with the generation number was broken. The load/store of
the current lock, the thread queue and the thread queue operations were not
properly synchronized. Under certain conditions on a PowerPC T4240 old
thread queue operations operated on a new thread queue (NULL pointer).
|
|
|
|
|
|
|
|
|
| |
A read-modify-write operation is necessary to read the last value
written.
See for example C11 standard or Power ISA 2.07, Book II: Power ISA
Virtual Environment Architecture, Section 1.6.3 Memory Coherence
Required [Category: Memory Coherence] and Section 1.7.3 Atomic Update.
|
|
|
|
|
|
|
|
|
|
|
| |
Move the safety check performed by
_CORE_mutex_Check_dispatch_for_seize() out of the performance critical
path and generalize it. Blocking on a thread queue with an unexpected
thread dispatch disabled level is illegal in all system states.
Add the expected thread dispatch disable level (which may be 1 or 2
depending on the operation) to Thread_queue_Context and use it in
_Thread_queue_Enqueue_critical().
|
|
|
|
|
|
|
|
|
|
|
| |
Unify the status codes of the Classic and POSIX API to use the new enum
Status_Control. This eliminates the Thread_Control::Wait::timeout_code
field and the timeout parameter of _Thread_queue_Enqueue_critical() and
_MPCI_Send_request_packet(). It gets rid of the status code translation
tables and instead uses simple bit operations to get the status for a
particular API. This enables translation of status code constants at
compile time. Add _Thread_Wait_get_status() to avoid direct access of
thread internal data structures.
|
| |
|
|
|
|
|
|
|
| |
We must call the MP callout for proxies if we unblock them after a
thread queue extraction. This was missing in
_Thread_queue_Flush_critical(). Move thread remove timer and unblock
code to new function _Thread_Remove_timer_and_unblock().
|
|
|
|
|
| |
Uniformly use *_Get() to get an object by identifier with a lock
context.
|
|
|
|
|
|
| |
Rename _Objects_Get_local() into _Objects_Get(). Confusions with the
previous _Objects_Get() function are avoided since the Objects_Locations
parameter is gone.
|
|
|
|
|
|
|
|
|
| |
Rename _ISR_Disable() into _ISR_Local_disable(). Rename _ISR_Enable()
into _ISR_Local_enable(). Remove _Debug_Is_owner_of_giant().
This is a preparation to remove the Giant lock.
Update #2555.
|
|
|
|
|
|
|
|
|
| |
Rename _ISR_Disable_without_giant() into _ISR_Local_disable(). Rename
_ISR_Enable_without_giant() into _ISR_Local_enable().
This is a preparation to remove the Giant lock.
Update #2555.
|