On 07/03/2014 10:11 AM, Kim De Mey wrote:
What I think that goes wrong is that the lock which is taken in
threadobj_notify_entry() is not released before threadobj_start()
continues at wait_on_barrier(thobj, __THREAD_S_ACTIVE).
Until threadobj_notify_entry() releases that lock, there is no way
wait_on_barrier() can exit, since it competes for the same lock.
pthread_cond_wait() will grab this lock before returning.
As there is a
t_delete() done right after t_start() returns in my test case, this
could mean that the thread gets in finalize_thread() after the
pthread_cancel() and blocks there on the threadobj_lock() as the
threadobj_unlock() from threadobj_notify_entry() was possibly not yet
called.
called? do you mean exited instead?
Until wait_on_barrier() unwinds for the child task, theadobj_start()
cannot complete for its parent, so the latter cannot delete the child it
has just spawned, until the latter has dropped the lock from
threadobj_notify_entry(). So I'm unsure the explanation stands - unless
I missed your point entirely.
This said, there must be something fishy as the backtrace clearly shows
a child thread hanging in the finalizer, waiting for access to its own tcb.
If you have a simple standalone test case illustrating this bug, please
send it along, this would save me some precious time trying to reproduce
the issue accurately. Otherwise I'll write one.
PS: mentioning the exact Xenomai 3 version you are running would always
help. Passing --version on the command line of any application built
over the copperplate-based APIs returns this information.
--
Philippe.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
