> > After some research I have ended up now in APC'c thread handling
>> > (see code snipped below, out of ksrc/arch/generic/hal.c). From my
>> > point of view there could be occur the "lost wakeup problem". That
>> > means in detail that rthal_kicker() calls wakeup when rthal_apc_thread()
>> > has returned from rthal_apc_handler() but not yet called
>> > set_current_state().
>> > After that, when kicker has finished, the APC thread calls
>> > set_current_state()
>> > and goes to sleep. Thus, the wakeup is lost. Or do I overlook something?
>> > Maybe we should use a waitqueue here?
>> >
>> >
>> > static int rthal_apc_thread(void *data)
>> > {
>> > unsigned cpu = (unsigned)(unsigned long)data;
>> >
>> > set_cpus_allowed(current, cpumask_of_cpu(cpu));
>> > sigfillset(¤t->blocked);
>> > current->flags |= PF_NOFREEZE;
>> > /* Use highest priority here, since some apc handlers might
>> > require to run as soon as possible after the request has been
>> > pended. */
>> > rthal_setsched_root(current, SCHED_FIFO, MAX_RT_PRIO - 1);
>> >
>> > while (!kthread_should_stop()) {
>> > set_current_state(TASK_INTERRUPTIBLE);
>> > schedule();
>>
>> You can obtain the same effect as with a wait queue by replacing the
>> schedule() above with:
>>
>> if (rthal_apc_pending[cpu] == 0)
>> schedule();
> else
> set_current_state(TASK_RUNNING);
Thanks for the hint, I like your approach. There we do not need to allocate a
waitqueue resource. Moreover the task wont be scheduled for every wakup call
but only as often as required. I will check if my application runs stable now
with
that fix. If true I will publish the patch here.
Regards,
Christoph
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
