On 2013-08-23 16:46, Gedare Bloom wrote:
This seems OK. I have not looked deeply enough but it bugs me that
maybe there is a race condition on the_thread->Wait.return_code also?
[...]
>+ } else {
>+ bool we_did_it;
>+
>+ _ISR_Enable( level );
>+
>+ /*
>+ * 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;
>+ }
I suppose you mean this area. 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.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
