| Commit message (Collapse) | Author | Files | Lines |
|---|
|
The thread queue implementation was heavily reworked to support SMP.
This broke the multiprocessing support of the thread queues. This is
fixed by this patch.
A thread proxy is unblocked due to three reasons
1) timeout,
2) request satisfaction, and
3) extraction.
In case 1) no MPCI message must be sent. This is ensured via the
_Thread_queue_MP_callout_do_nothing() callout set during
_Thread_MP_Allocate_proxy().
In case 2) and 3) an MPCI message must be sent. In case we interrupt
the blocking operation during _Thread_queue_Enqueue_critical(), then
this message must be sent by the blocking thread. For this the new
fields Thread_Proxy_control::thread_queue_callout and
Thread_Proxy_control::thread_queue_id are used.
Delete the individual API MP callout types and use
Thread_queue_MP_callout throughout. This type is only defined in
multiprocessing configurations. Prefix the multiprocessing parameters
with mp_ to ease code review. Multiprocessing specific parameters are
optional due to use of a similar macro pattern. There is no overhead
for non-multiprocessing configurations.
|
|
This field was only by the monitor in non-multiprocessing
configurations. Add new field Thread_Wait_information::remote_id in
multiprocessing configurations and use it for the remote procedure call
thread queue.
Add _Thread_Wait_get_id() to obtain the object identifier for debug and
system information tools. Ensure the object layout via static asserts.
Add test cases to sptests/spthreadq01.
|
|
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 type is superfluous since all operations with it are done via the
_Timestamp_*() functions.
|
|
Update #2408.
|
|
This avoids potential dead code in _Thread_Handler(). It gets rid of
the dangerous function pointer casts.
Update #2514.
|
|
Notepads where a feature of RTEMS' tasks that simply functioned in
the same way as POSIX keys or threaded local storage (TLS). They were
introduced well before per task variables, which are also deprecated,
and were barely used in favor of their POSIX alternatives.
In addition to their scarce usage, Notepads took up unnecessary memory.
For each task:
- 16 32-bit integers were allocated.
- A total of 64 bytes per task per thread.
This is especially critical in low memory and safety-critical applications.
They are also defined as uint32_t, and therefore are not guaranteed to
hold a pointer.
Lastly, they are not portable solutions for SMP and uniprocessor systems,
like POSIX keys and TLS.
updates #2493.
|
|
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.
|
|
Add a leading underscore to the structure name to allow forward
declarations in standard header files provided by Newlib and GCC.
|
|
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).
|
|
Separate the thread queue heads and lock from the operations. This
enables the support for light weight objects which only support one
queuing discipline.
|
|
Avoid Thread_Control typedef in <rtems/score/percpu.h>. This helps to
get rid of the <rtems/score/percpu.h> include in <rtems/score/thread.h>
which exposes a lot of implementation details.
|
|
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.
|
|
Store the floating-point unit property in the thread control block
regardless of the CPU_HARDWARE_FP and CPU_SOFTWARE_FP settings. Make
sure the floating-point unit is only enabled for the corresponding
multilibs. This helps targets which have a volatile only floating point
context like SPARC for example.
|
|
Move the writes to Thread_Control::current_priority and
Thread_Control::real_priority into _Thread_Change_priority() under the
protection of the thread lock. Add a filter function to
_Thread_Change_priority() to enable specialized variants.
Avoid race conditions during a thread priority restore with the new
Thread_Control::priority_restore_hint for an important average case
optimizations used by priority inheritance mutexes.
Update #2273.
|
|
Move thread queue discipline specific operations into
Thread_queue_Operations. Use a separate node in the thread control
block for the thread queue to make it independent of the scheduler data
structures.
Update #2273.
|
|
Replace the Thread_Priority_control with more general
Thread_queue_Operations which will be used for generic priority change,
timeout, signal and wait queue operations in the future.
Update #2273.
|
|
Add a thread wait timeout code. Replace _Event_Timeout() with a general
purpose _Thread_Timeout() watchdog handler.
Update #2273.
|
|
Merge THREAD_WAIT_STATE_SATISFIED, THREAD_WAIT_STATE_TIMEOUT,
THREAD_WAIT_STATE_INTERRUPT_SATISFIED, and
THREAD_WAIT_STATE_INTERRUPT_TIMEOUT into one state
THREAD_WAIT_STATE_READY_AGAIN. This helps to write generic routines to
block a thread.
Update #2273.
|
|
Fix layout of the common block of Thread_Control and
Thread_Proxy_control. Ensure that the offsets match.
|
|
The Objects_Control::Lock was a software layer violation. It worked
only for the threads since they are somewhat special.
Update #2273.
|
|
Update #2273.
|
|
Since the thread current priority change and thread queue requeue is
performed in one critical section it is possible to simplify the thread
queue requeue procedure. Add a thread queue agnostic thread priority
change handler so that we are able to use alternative thread queue
implementations.
Update #2273.
|
|
Atomically update the current priority of a thread and the wait queue.
Serialize the scheduler update in a separate critical section with a
generation number.
New test sptests/spintrcritical23.
Close #2310.
|
|
|
|
Update #2273.
|
|
|
|
This field is no longer used.
|
|
|
|
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.
|
|
Add Thread_Scheduler_control to collect scheduler related fields of the
TCB.
|
|
|
|
|
|
|
|
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 current implementation of task migration in RTEMS has some
implications with respect to the interrupt latency. It is crucial to
preserve the system invariant that a task can execute on at most one
processor in the system at a time. This is accomplished with a boolean
indicator in the task context. The processor architecture specific
low-level task context switch code will mark that a task context is no
longer executing and waits that the heir context stopped execution
before it restores the heir context and resumes execution of the heir
task. So there is one point in time in which a processor is without a
task. This is essential to avoid cyclic dependencies in case multiple
tasks migrate at once. Otherwise some supervising entity is necessary to
prevent life-locks. Such a global supervisor would lead to scalability
problems so this approach is not used. Currently the thread dispatch is
performed with interrupts disabled. So in case the heir task is
currently executing on another processor then this prolongs the time of
disabled interrupts since one processor has to wait for another
processor to make progress.
It is difficult to avoid this issue with the interrupt latency since
interrupts normally store the context of the interrupted task on its
stack. In case a task is marked as not executing we must not use its
task stack to store such an interrupt context. We cannot use the heir
stack before it stopped execution on another processor. So if we enable
interrupts during this transition we have to provide an alternative task
independent stack for this time frame. This issue needs further
investigation.
|
|
|
|
Clustered/partitioned scheduling helps to control the worst-case
latencies in the system. The goal is to reduce the amount of shared
state in the system and thus prevention of lock contention. Modern
multi-processor systems tend to have several layers of data and
instruction caches. With clustered/partitioned scheduling it is
possible to honour the cache topology of a system and thus avoid
expensive cache synchronization traffic.
We have clustered scheduling in case the set of processors of a system
is partitioned into non-empty pairwise-disjoint subsets. These subsets
are called clusters. Clusters with a cardinality of one are partitions.
Each cluster is owned by exactly one scheduler instance.
|
|
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.
|
|
Per task variables are inherently unsafe in SMP systems. This
patch disables them from the build and adds warnings in the
appropriate documentation and configuration sections.
|
|
|
|
The thread deletion is now supported on SMP.
This change fixes the following PRs:
PR1814: SMP race condition between stack free and dispatch
PR2035: psxcancel reveals NULL pointer access in _Thread_queue_Extract()
The POSIX cleanup handler are now called in the right context (should be
called in the context of the terminating thread).
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
Add a user extension the reflects a thread termination event. This is
used to reclaim the Newlib reentrancy structure (may use file
operations), the POSIX cleanup handlers and the POSIX key destructors.
|
|
The thread restart is now supported on SMP. New test
smptests/smpthreadlife01.
|
|
Thread actions are the building block for efficient implementation of
- Classic signals delivery,
- POSIX signals delivery,
- thread restart notification,
- thread delete notification,
- forced thread migration on SMP configurations, and
- the Multiprocessor Resource Sharing Protocol (MrsP).
|
|
|
|
Formerly POSIX keys were only enabled when POSIX threads
were enabled. Because they are a truly safe alternative
to per-task variables in an SMP system, they are being
enabled in all configurations.
|
|
|
