Ah, Ok. Thanks for the clarification.
On Fri, Aug 23, 2013 at 2:28 PM, Sebastian Huber
<sebastian.hu...@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.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
