On 2011-07-12 13:41, Gilles Chanteperdrix wrote: > On 07/12/2011 01:29 PM, Jan Kiszka wrote: >>> I find all this complicated for a very small corner-case, so, I keep >>> looking for a simpler solution. Let us try something else. >> >> It's rather the contrary: this solution is straightforward IMHO. >> >>> >>> If the thread is woken up for whatever reason before the gatekeeper, >>> then we will hit the following "if" in xnshadow_harden, can we set the >>> target to NULL at this point if it is the current thread? With a cmpxchg >>> perhaps? >> >> Gatekeeper and target task aren't synchronized, are they? > > That is another reason why the solution to synchronize using the > semaphore may not work. If the thread hits the call to down before the
"thread" means do_taskexit_event here? > gatekeeper is woken up, then the gatekeeper test may see the target > thread as suspended, and we may return from the call to "down" in > xenomai domain. Good point, but fortunately not possible: If we block on down() in do_taskexit_event, we enter TASK_UNINTERRUPTIBLE state. But the gatekeeper checks for TASK_INTERRUPTIBLE. However, this parallel unsynchronized execution of the gatekeeper and its target thread leaves an increasingly bad feeling on my side. Did we really catch all corner cases now? I wouldn't guarantee that yet. Specifically as I still have an obscure crash of a Xenomai thread on Linux schedule() on my table. What if the target thread woke up due to a signal, continued much further on a different CPU, blocked in TASK_INTERRUPTIBLE, and then the gatekeeper continued? I wish we could already eliminate this complexity and do the migration directly inside schedule()... Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
