On Wed, Dec 17, 2014 at 12:24:23PM +0000, Stoidner, Christoph wrote:
>
> 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();
However, using a wait queue will make the code easier to read.
> rthal_apc_handler(0, NULL);
> }
>
> __set_current_state(TASK_RUNNING);
>
> return 0;
> }
>
> void rthal_apc_kicker(unsigned virq, void *cookie)
> {
> wake_up_process(rthal_apc_servers[smp_processor_id()]);
> }
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
