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?

-- 
                                                                Gilles.

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

Reply via email to