Jan Kiszka wrote:
 > Hi,
 > Gilles' work on cancellation for the posix skin reminded me of this
 > issue I once discovered in the native skin:
 > https://mail.gna.org/public/xenomai-core/2005-12/msg00014.html
 > I found out that this can easily be fixed by switching the pthread of a
 > native task to PTHREAD_CANCEL_ASYNCHRONOUS. See attached patch.
 > At this chance I discovered that calling rt_task_delete for a task that
 > was created and started with T_SUSP mode but was not yet resumed, locks
 > up the system. More precisely: it raises a fatal warning when
 > XENO_OPT_DEBUG is on. Might be the case that it just works on system
 > without this switched on. Either this is a real bug, or the warning
 > needs to be fixed. (Deleting a task after rt_task_suspend works.)

Actually, the fatal warning happens when starting with rt_task_start the
task which was created with the T_SUSP bit. The task needs to wake-up in
xnshadow_wait_barrier until it gets really suspended in primary mode by
the final xnshadow_harden. This situation triggers the fatal, because
the thread has the nucleus XNSUSP bit and is running in secondary mode.

This is not the only situation where a thread with a nucleus suspension
bit need to run shortly in secondary mode: it also occurs when
suspending with xnpod_suspend_thread() a thread running in secondary
mode; the thread receives the SIGCHLD signal and need to execute shortly
with the suspension bit set in order to cause a migration to primary

So, the only case when we are sure that a user-space thread can not be
scheduled by Linux seems to be when this thread does not have the


                                            Gilles Chanteperdrix.

Xenomai-core mailing list

Reply via email to