Am 03.11.2010 23:03, Jan Kiszka wrote:
> Am 03.11.2010 21:41, Philippe Gerum wrote:
>> On Wed, 2010-11-03 at 20:38 +0100, Anders Blomdell wrote:
>>> Jan Kiszka wrote:
>>>> Am 03.11.2010 17:46, Anders Blomdell wrote:
>>>>> Anders Blomdell wrote:
>>>>>> Anders Blomdell wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> additional barrier. Can you check this?
>>>>>>>>
>>>>>>>> diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
>>>>>>>> index df56417..66b52ad 100644
>>>>>>>> --- a/include/nucleus/sched.h
>>>>>>>> +++ b/include/nucleus/sched.h
>>>>>>>> @@ -187,6 +187,7 @@ static inline int xnsched_self_resched_p(struct
>>>>>>>> xnsched *sched)
>>>>>>>> if (current_sched != (__sched__)) { \
>>>>>>>> xnarch_cpu_set(xnsched_cpu(__sched__),
>>>>>>>> current_sched->resched); \
>>>>>>>> setbits((__sched__)->status, XNRESCHED); \
>>>>>>>> + xnarch_memory_barrier(); \
>>>>>>>> } \
>>>>>>>> } while (0)
>>>>>>> In progress, if nothing breaks before, I'll report status tomorrow
>>>>>>> morning.
>>>>>> It still breaks (in approximately the same way). I'm currently putting a
>>>>>> barrier in the other macro doing a RESCHED, also adding some tracing to
>>>>>> see if a read barrier is needed.
>>>>> Nope, no luck there either. Will start interesting tracepoint
>>>>> adding/conversion :-(
>>>>
>>>> Strange. But it was too easy anyway...
>>>>
>>>>> Any reason why xn_nucleus_sched_remote should ever report status = 0?
>>>>
>>>> Really don't know yet. You could trigger on this state and call
>>>> ftrace_stop() then. Provided you had the functions tracer enabled, that
>>>> should give a nice pictures of what happened before.
>>>
>>> Isn't there a race betweeen these two (still waiting for compilation to
>>> be finished)?
>>
>> We always hold the nklock in both contexts.
>>
>
> 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. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
