Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 03.11.2010 23:11, Jan Kiszka wrote:
>>> Am 03.11.2010 23:03, Jan Kiszka wrote:
>>>> But we not not always use atomic ops for manipulating status bits (but
>>>> we do in other cases where this is no need - different story). This may
>>>> fix the race:
>>> Err, nonsense. As we manipulate xnsched::status also outside of nklock
>>> protection, we must _always_ use atomic ops.
>>>
>>> This screams for a cleanup: local-only bits like XNHTICK or XNINIRQ
>>> should be pushed in a separate status word that can then be safely
>>> modified non-atomically.
>>
>> Second try to fix and clean up the sched status bits. Anders, please
>> test.
>>
>> Jan
>>
>> diff --git a/include/nucleus/pod.h b/include/nucleus/pod.h
>> index 01ff0a7..5987a1f 100644
>> --- a/include/nucleus/pod.h
>> +++ b/include/nucleus/pod.h
>> @@ -277,12 +277,10 @@ static inline void xnpod_schedule(void)
>>       * context is active, or if we are caught in the middle of a
>>       * unlocked context switch.
>>       */
>> -#if XENO_DEBUG(NUCLEUS)
>>      if (testbits(sched->status, XNKCOUT|XNINIRQ|XNSWLOCK))
>>              return;
>> -#else /* !XENO_DEBUG(NUCLEUS) */
>> -    if (testbits(sched->status,
>> -                 XNKCOUT|XNINIRQ|XNSWLOCK|XNRESCHED) != XNRESCHED)
>> +#if !XENO_DEBUG(NUCLEUS)
>> +    if (!sched->resched)
>>              return;
>>  #endif /* !XENO_DEBUG(NUCLEUS) */
> 
> Having only one test was really nice here, maybe we simply read a
> barrier before reading the status?
> 

I agree - but the alternative is letting all modifications of
xnsched::status use atomic bitops (that's required when folding all bits
into a single word). And that should be much more costly, specifically
on SMP.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to