[kaffe] analysis of pthread spec violation (leads to deadlock on recent glibc)
guilhem at kaffe.org
Tue Sep 28 13:28:02 PDT 2004
I am totally for a logical ordering of destruction operation.
Noa Resare wrote:
> - pthread_cond_wait() gets called from exitThread() in thread.c (via
> unlinkNativeAndJavaThread() -> ksemDestroy() -> jcondvar_destroy())
> - thereafter jthread_exit() gets called in exitThread() and is
> advertised as not returning. This is not true. As can be found in
> systems/unix-pthreads/thread-impl.c if certain conditions are met it
> just returns. when exitThread() returns control is moved to tRun in
jthread_exit() should not return. I haven't noticed that. :( I would
suggest a special longjmp to reset the stack and go back in the tRun
loop directly (though I don't know if it is really legal).
> - before tRun() goes on to remove the current thread from the
> activeThreads list it calls TLOCK() calls pthread_cond_wait() (via
> lockStaticMutex() -> locks_internal_lockMutex() -> slowLockMutex() ->
> ksemGet() -> jcondvar_wait())
> The obvious way of fixing this IMHO is to delay the
> unlinkNativeAndJavaThread() invocation until the threads implementation
> has removed the current thread from the activeThreads list. However this
Hmm... maybe we should change how the thread context is destroyed.
unlinkNativeAndJavaThread may be a callback for the threading system so
it is called whenever a thread exits and it has already been removed
from the active list. It will keep the VM parts in the VM and will give
us a way to introduce some sort of specific "finalization".
> has an obvious drawback that a required step in thread deconstruction is
> moved from generic code to threading implementation specific code. (In
> other words, it needs to be fixed or at leased verified as non-
> problematic in all threading implementations).
> What threading implementations are a priority? Since unix-pthread is
> seriously broken at the moment and I suppose that it is by far the most
> commonly used threading implementation fixing it is worth some breakage
> in lesser used ones.
> I can take responsibility for testing a proposed fix on unix-jthread but
> are there anyone out there taking responsibility for win32, beos-native
> and oskit-pthreads? Are they used by anyone?
ATM, I am only aware of unix-jthreads and unix-pthreads users. The other
threading system are well behind the current design I think (I've
already evolved the interface but not all as I don't have access to
More information about the kaffe