On Fri, Feb 1, 2008 at 11:10 AM, Philippe Gerum <[EMAIL PROTECTED]> wrote:
>
> Gilles Chanteperdrix wrote:
> > Gilles Chanteperdrix wrote:
> > >
> > > Hi Philippe,
> > >
> > > here comes a new patch on the theme "reworking self deletion". This
> > > time, execution of nkpod delete hooks is made before the context switch
> > > whereas finalizing the thread takes place after the context
> > > switch. Special care has been taken to call xnfreesync before we run the
> > > hooks, in order to avoid freeing the thread control block before the
> > > finalization, and xnheap_t::idleq was made a per-cpu thing for the same
> > > purpose.
> > >
> > > I made a simple watchdog test with all debugs enabled, and
> > > xnshadow_unmap did not complain.
> > >
> > > If you are OK with this patch, I will rebase the unlocked context switch
> > > patch on it.
> >
> > Thinking a bit more about the unlocked context switch case: do we
> > tolerate that an ISR may delete a thread that is not current ? Because
> > if an ISR deleted a non current thread, we would not run the hooks over
> > the deleted thread context, so we would be again in the case where
> > xnshadow_unmap is not run by current. Besides, at first sight, it seems
> > to simplify greatly the case of the unlocked context switch.
> >
>
> No we don't; thread deletion is normally a service callable from thread
> context only. We allow the watchdog code to call into
> xnpod_delete_thread() as an exception, because we have no other mean to
> fix the runaway situation properly, and we know that this will work
> precisely because the deleted thread is current.
>
> Any other situation would lockup, because the termination signal would
> never make it to the runaway thread since Linux is starved from CPU at
> that point, and we can't even relax the thread either. So, yes, we may
> safely assume that thread deletion is either called from a thread, or
> called on behalf of an ISR for the preempted thread only (and solely for
> internal code and well-know situations).
Unfortunately, my reasoning was UP only, in SMP, it may happen that a
distant CPU deletes from a valid context the thread being currently
switched out with nklock unlocked on current CPU. So, we have to take
care about this case anyway.
--
Gilles Chanteperdrix
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
