diff options
author | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2014-03-27 09:04:47 +0100 |
---|---|---|
committer | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2014-04-01 14:10:22 +0200 |
commit | 91e7b0c5ae837c055fd67d77d8db26bfb648261b (patch) | |
tree | 8a4ec85b7c38da0e27b5c2e5162b95b8338dfb1b /cpukit/libcsupport/include | |
parent | libchip: Avoid __DEVOLATILE() (diff) | |
download | rtems-91e7b0c5ae837c055fd67d77d8db26bfb648261b.tar.bz2 |
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.
Diffstat (limited to 'cpukit/libcsupport/include')
0 files changed, 0 insertions, 0 deletions