| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add RTEMS_PREDICT_TRUE() and RTEMS_PREDICT_FALSE() for static branch
prediction hints.
Close #3475.
|
|
Update #3117.
Update #3182.
|
|
Rename _Thread_queue_Context_set_do_nothing_enqueue_callout() into
_Thread_queue_Context_set_enqueue_do_nothing_extra(). More
_Thread_queue_Context_set_enqueue_*() functions will follow.
Update #3117.
Update #3182.
|
|
|
|
Update #2858.
|
|
Add thread state bit to identify thread queues that are embedded in an
object with identifier.
|
|
Only require that the Newlib defined structure is big enough.
|
|
Move thread state for _Thread_queue_Enqueue() to the thread queue
context. This reduces the parameter count of _Thread_queue_Enqueue()
from five to four (ARM for example has only four function parameter
registers). Since the thread state is used after several function calls
inside _Thread_queue_Enqueue() this parameter was saved on the stack
previously.
|
|
Delete unused _Thread_queue_Enqueue() and rename
_Thread_queue_Enqueue_critical() to _Thread_queue_Enqueue().
|
|
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.
|
|
Avoid use of the stack for the hot paths.
|
|
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.
|
|
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
|
|
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.
|
|
Drop the multiprocessing (MP) dependent callout parameter from the
thread queue extract, dequeue, flush and unblock methods. Merge this
parameter with the lock context into new structure Thread_queue_Context.
This helps to gets rid of the conditionally compiled method call
helpers.
|
|
Get rid of the mp_id parameter used for some thread queue methods. Use
THREAD_QUEUE_QUEUE_TO_OBJECT() instead.
|
|
|
|
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.
|
|
|
