Date: Tue, 9 Mar 1999 17:26:26 -0800 From: John Plevyak <jplevyak@inktomi.com> To: dick@tar.com Cc: hackers@freebsd.org Subject: bug in linuxthreads for FreeBSD Message-ID: <19990309172626.A7182@proxydev.inktomi.com>
next in thread | raw e-mail | index | archive | help
I have been using the linuxthreads for FreeBSD port, and running
it under high stress.
It seems that there is a bug/race which triggers the ASSERT in queue.h.
Essentially the problem is that when a thread goes into
pthread_cond_timedwait (and hence pthread_cond_timedwait_relative)
there is a race between the timeout wakeup and the signal wakeup.
Here is the order of events which exhibits the bug:
T1: thread A goes into pthread_cond_timedwait_relative and puts
itself on the cond->c_waiting queue.
T2: thread A wakes up from a timeout and blocks the restart signal
T3: (context switch) thread B triggers the conditional variable,
and send the signal
T4: (context switch) thread A grabs the spinlock and tries
to remove_from_queue() (which fails silently)
T5: thread A goes into pthread_cond_timedwait_relative again
as soon as it unblocks the restart it is awoken (NOTE: it
is still on cond->c_waiting.
T6: (another thread blocks on the condition variable,
so that th->p_nextwaiting != NULL)
T7: thread A tries to block on a mutex which sees that
self->p_nextwaiting != NULL and asserts.
The patch I am using unconditionally removes the thread from the
queue. This does not prevent the thread from being woken up
extaneously, but it does prevent the ASSERT and corruption of
the p_nextwaiting lists.
This looks like it may be a general problem with linuxthreads,
and I am wondering if anyone else has seen it.
Also, there is no 'lock prefix' before the xchg in _atomic_lock.S which
will prevent the library from working correctly with SMP.
john
--
John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD
Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403
W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990309172626.A7182>