gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp

I ran into a test failure on gdb.python/py-thread-exited.c.  The test
creates two threads and then catches the thread exits in Python.  The
test expects the threads to exit in a specific order.

As the test is currently written, it is _likely_, but not guaranteed,
that the threads will exit in the same order they are created, which
is what the test expects.

When running on a loaded system I ran into a case where the threads
exited in the reverse creation order, which caused the test to fail.

I could fix this by having the .exp file not care about the thread
order, or by changing the C file to force the order. I chose the
later, and added a pthread_barrier_t to ensure the threads exit in the
correct order.

There should be no change in what is tested after this commit.

diff --git a/gdb/testsuite/gdb.python/py-thread-exited.c b/gdb/testsuite/gdb.python/py-thread-exited.c
index d62133ba59e54d315b219e5370cf94437bfdf2e6..4df6b5879354331230f05a40d04c31774e847cc1 100644 (file)
--- a/gdb/testsuite/gdb.python/py-thread-exited.c
+++ b/gdb/testsuite/gdb.python/py-thread-exited.c
@@ -24,14 +24,25 @@ pthread_t thread3_id;
 
 void* do_thread (void* d)
 {
+  if (d != NULL)
+    {
+      pthread_barrier_t *barrier = (pthread_barrier_t *) d;
+      pthread_barrier_wait (barrier);
+    }
+
   return NULL;                 /* In thread */
 }
 
 int main (void)
 {
+  /* We want the threads to exit in a known order.  Use a barrier to ensure
+     the second thread doesn't exit until the first has been joined.  */
+  pthread_barrier_t barrier;
+  pthread_barrier_init (&barrier, NULL, 2);
   pthread_create (&thread2_id, NULL, do_thread, NULL);
-  pthread_create (&thread3_id, NULL, do_thread, NULL);
+  pthread_create (&thread3_id, NULL, do_thread, &barrier);
   pthread_join (thread2_id, NULL);
+  pthread_barrier_wait (&barrier);
   pthread_join (thread3_id, NULL);
   return 12;                   /* Done */
 }