[kaffe] SMP and pthreads

Guilhem Lavaux 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:

<signal handler>
futex syscall

and the other one is:
futex syscall
GC thread

When I look into the kernel source tree I see this:
static int futex_wait(unsigned long uaddr, int val, unsigned long time)
        DECLARE_WAITQUEUE(wait, current);
        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;
        int ret;


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.


Guilhem Lavaux.

More information about the kaffe mailing list