[PATCH 2/2] score: PR2140: Fix _Thread_queue_Process_timeout()

[Sebastian Huber]

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.