[kaffe] analysis of pthread spec violation (leads to deadlock on recent glibc)

[Guilhem Lavaux]

Hi Noa,

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
> thread-impl.c

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 
those systems).


Cheers,

Guilhem Lavaux.