This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] testsuite: Fix a race by me - watchthreads-reorder.exp
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 17 Dec 2009 13:27:24 -0700
- Subject: Re: [patch] testsuite: Fix a race by me - watchthreads-reorder.exp
- References: <20091217195026.GA21468@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> there is a bug explainable by man pthread_cond_signal:
Jan> The [...] pthread_cond_signal() functions shall have no effect if
Jan> there are no threads currently blocked on cond.
Jan> + i = pthread_cond_wait (&thread1_tid_cond, &thread1_tid_mutex);
Jan> + assert (i == 0);
pthread_cond_wait can also spuriously wake up. The usual thing to do is
call it in a loop that checks some condition. Then, have the signalling
thread set the condition before calling pthread_cond_signal. Something
like:
while (thread1_tid == 0)
pthread_cond_wait (...);
This is race-free as long as the signalling thread also acquires the
mutex associated with the condition.
Is there some reason not to do this in this test case?
Tom