Jan Kiszka wrote: > Am 04.11.2010 00:18, Gilles Chanteperdrix wrote: >> 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 >>>>> 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. >> What about issuing a barrier before testing the status? >> > > The problem is not about reading but writing the status concurrently, > thus it's not about the code you see above.
The bits are modified under nklock, which implies a barrier when unlocked. Furthermore, an IPI is guaranteed to be received on the remote CPU after this barrier, so, a barrier should be enough to see the modifications which have been made remotely. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core