Jan Kiszka wrote:
> 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
>>> 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))
>>> -#else /* !XENO_DEBUG(NUCLEUS) */
>>> - if (testbits(sched->status,
>>> - XNKCOUT|XNINIRQ|XNSWLOCK|XNRESCHED) != XNRESCHED)
>>> +#if !XENO_DEBUG(NUCLEUS)
>>> + if (!sched->resched)
>>> #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.
What about issuing a barrier before testing the status?
Xenomai-core mailing list