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

[Gedare Bloom]

Ah, Ok. Thanks for the clarification.

On Fri, Aug 23, 2013 at 2:28 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.
>