[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible race condition in linuxthreads-0.9 (i386, LDT)
From: |
alvin |
Subject: |
Re: possible race condition in linuxthreads-0.9 (i386, LDT) |
Date: |
Mon, 16 Jul 2001 15:41:26 -0400 |
Ed Connell wrote:
>
> It sounds like you are having the same problem I've been having for
> the past several weeks. Check out
> http://sources.redhat.com/ml/bug-glibc/2001-06/msg00079.html or
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0106.2/0472.html
> for my description of the problem. The basic idea is, a multithreaded
> program on an SMP box seems to run fine except when 'exec'd from
> a shell script where I get intermittant crashes and hangs. Removing
> CPU's down to one or booting a uniprocessor kernel makes the
> problem go away.
>
> I've been playing with linuxthreads and the kernel trying to figure out
> what's going on. Linuxthreads makes clone calls from time to time
> to create new threads. Occasionally, it seems that the cloned
> process is getting a SEGV as it is being scheduled for the very first
> time. As far as I can tell this is happening in the switch_to() macro
> call in schedule() (kernel/sched.c). This happens before the original
> cloning process is even done with the do_fork() call which is a little
> unnerving.
>
> I'm not sure if the kernel or linuxthreads is at fault. I will continue to
> poke around at this problem. Suggestions encouraged.
In pthread.c in the routine __pthread_create_2_1. There is a call to
suspend. When suspend returns there is no check to see if the thread has
actually been created. This is where the problem arises.
I assert that if you call suspend and are wating for an event you should
test to see if that event has actully occured.
I had this problem and fixed it by looping on a sched_yield until the
initalization is complete.
--
Alvin Starr || voice: (416)585-9971
Interlink Connectivity || fax: (416)785-3668
address@hidden ||