This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] testsuite: Fix a race by me - watchthreads-reorder.exp


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]