Changeset 91e7b0c in rtems
- Timestamp:
-
03/27/14 08:04:47
(10 years ago)
- Author:
- Sebastian Huber <sebastian.huber@…>
- Branches:
- 4.11, 5, master
- Children:
- 25a97835
- Parents:
- 8118b670
- git-author:
- Sebastian Huber <sebastian.huber@…> (03/27/14 08:04:47)
- git-committer:
- Sebastian Huber <sebastian.huber@…> (04/01/14 12:10:22)
- Message:
-
score: PR2172: _Thread_queue_Extract()
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.
-
(No files)
-