Hi!
The last probelm I've occassionally saw FAILing under high load
was a thinko in thread-limit-1.c test.
The test meant to verify that no more than omp_get_thread_limit ()
total threads are running in the same contention group, but foolishly
assumed that all the nested GOMP_parallels will happen about at the same
time and thus there will be at most 6 threads running totally.
But, if some threads run through quickly and finish, while others are slow
to reach GOMP_barrier, then the ThreadsBusy counter might be already
decremented before deciding how many threads are allowed to be started,
so we could increment cnt more than 6 times.
This patch rewrites it such that it really tests if no more than 6
threads are running at the same time.
2013-10-08 Jakub Jelinek <ja...@redhat.com>
* testsuite/libgomp.c/thread-limit-1.c (main): Check if
cnt isn't bigger than 6 at any point in time, sleep 10ms after
incrementing it and then atomically decrement.
* testsuite/libgomp.c/thread-limit-2.c (main): Likewise.
--- libgomp/testsuite/libgomp.c/thread-limit-1.c.jj 2013-10-04
15:41:48.000000000 +0200
+++ libgomp/testsuite/libgomp.c/thread-limit-1.c 2013-10-08
20:30:47.841114157 +0200
@@ -27,9 +27,15 @@ main ()
#pragma omp parallel num_threads (5)
#pragma omp parallel num_threads (5)
#pragma omp parallel num_threads (2)
- #pragma omp atomic
- cnt++;
- if (cnt > 6)
- abort ();
+ {
+ int v;
+ #pragma omp atomic capture
+ v = ++cnt;
+ if (v > 6)
+ abort ();
+ usleep (10000);
+ #pragma omp atomic
+ --cnt;
+ }
return 0;
}
--- libgomp/testsuite/libgomp.c/thread-limit-2.c.jj 2013-10-04
15:48:28.000000000 +0200
+++ libgomp/testsuite/libgomp.c/thread-limit-2.c 2013-10-08
20:32:34.281578026 +0200
@@ -41,10 +41,16 @@ main ()
#pragma omp parallel num_threads (5)
#pragma omp parallel num_threads (5)
#pragma omp parallel num_threads (2)
- #pragma omp atomic
- cnt++;
- if (cnt > 6)
- abort ();
+ {
+ int v;
+ #pragma omp atomic capture
+ v = ++cnt;
+ if (v > 6)
+ abort ();
+ usleep (10000);
+ #pragma omp atomic
+ --cnt;
+ }
}
}
return 0;
Jakub
