On Wed, Dec 17, 2014 at 02:22:35PM +0100, Gilles Chanteperdrix wrote:
> 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();
else
set_current_state(TASK_RUNNING);
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
