Delete global variables _Priority_Major_bit_map and _Priority_Bit_map.
This makes it possible to use multiple priority scheduler instances for
example with clustered/partitioned scheduling on SMP.
Issue a fatal error in case a thread is deleted which still owns
resources (e.g. a binary semaphore with priority inheritance or ceiling
protocol). The resource count must be checked quite late since RTEMS
task variable destructors, POSIX key destructors, POSIX cleanup handler,
the Newlib thread termination extension or other thread termination
extensions may release resources. In this context it would be quite
difficult to return an error status to the caller.
An alternative would be to place threads with a non-zero resource count
not on the zombie chain. Thus we have a resource leak instead of a
fatal error. The terminator thread can see this error if we return an
RTEMS_RESOURCE_IN_USE status for the rtems_task_delete() for example.
Add _Thread_queue_Extract_with_return_code(). On SMP this sequence in
_Thread_queue_Process_timeout() was broken:
[...]
/*
* After we enable interrupts here, a lot may happen in the
* meantime, e.g. nested interrupts may release the resource that
* times out here. So we enter _Thread_queue_Extract()
* speculatively. Inside this function we check the actual status
* under ISR disable protection. This ensures that exactly one
* executing context performs the extract operation (other parties
* may call _Thread_queue_Dequeue()). If this context won, then
* we have a timeout.
*
* We can use the_thread_queue pointer here even if
* the_thread->Wait.queue is already set to NULL since the extract
* operation will only use the thread queue discipline to select
* the right extract operation. The timeout status is set during
* thread queue initialization.
*/
we_did_it = _Thread_queue_Extract( the_thread_queue, the_thread );
if ( we_did_it ) {
the_thread->Wait.return_code = the_thread_queue->timeout_status;
}
[...]
In case _Thread_queue_Extract() successfully extracted a thread, then
this thread may start execution on a remote processor immediately and
read the the_thread->Wait.return_code before we update it here with the
timeout status. Thus it observes a successful operation even if it
timed out.
The holder field is enough to determine if a mutex is locked or not.
This leads also to better error status codes in case a
rtems_semaphore_release() is done for a mutex without having the
ownership.
Joel Sherrill
Sebastian Huber
Jennifer Averett
Daniel Cederman
Pavel Pisa