[kaffe] SMP and pthreads
guilhem at kaffe.org
Sat Jan 1 03:41:48 PST 2005
I have checked how the linux kernel handles futex and I see a potential
problem. When kaffe deadlocks with GCTest it is always hang with one
thread in a pthread_mutex_unlock calling the futex syscall and the GC
thread in pthread_mutex_lock calling the futex syscall. The first thread
has been interrupted during the syscall by the GC when the world has
been suspended. So the stack is:
and the other one is:
When I look into the kernel source tree I see this:
static int futex_wait(unsigned long uaddr, int val, unsigned long time)
int ret, curval;
struct futex_q q;
the kernel then prepares the locking and unlock mmap_sem.
static int futex_wake(unsigned long uaddr, int nr_wake)
union futex_key key;
struct futex_hash_bucket *bh;
struct list_head *head;
struct futex_q *this, *next;
the kernel iterates the semaphores and wakes up all threads.
what may happen if the signal handler is called after down_read in
futex_wake ? => we are not able to call futex_wait because the
application will deadlock because the first thread is frozen by a sigwait.
So either we have a limitation of the kernel either a bug if the
analysis is correct. The only point is that I am not sure whether a
signal is allowed to interrupt a syscall just in the middle futex_wake.
More information about the kaffe