public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [committed][gdb/testsuite] Stabilize execution order in omp-par-scope.c
@ 2020-07-20 12:42 Tom de Vries
  2020-07-21  1:51 ` Kevin Buettner
  0 siblings, 1 reply; 2+ messages in thread
From: Tom de Vries @ 2020-07-20 12:42 UTC (permalink / raw)
  To: gdb-patches

Hi,

In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
on omp_get_thread_num ().  Since execution order of the threads can vary from
execution to execution, this can cause changes in test results.

F.i., we can see this difference between two test runs:
...
-KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
+PASS: single_scope: first thread: print i3
-PASS: single_scope: second thread: print i3
+KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
...
In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
that corresponds to the first thread executing that bit of code, and in the
other case to the second thread.

Get rid of this difference by stabilizing execution order.

Tested on x86_64-linux.

Committed to trunk.

Thanks,
- Tom

[gdb/testsuite] Stabilize execution order in omp-par-scope.c

gdb/testsuite/ChangeLog:

2020-07-20  Tom de Vries  <tdevries@suse.de>

	* gdb.threads/omp-par-scope.c (lock, lock2): New variable.
	(omp_set_lock_in_order): New function.
	(single_scope, multi_scope, nested_func, nested_parallel): Use
	omp_set_lock_in_order and omp_unset_lock.
	(main): Init and destroy lock and lock2.

---
 gdb/testsuite/gdb.threads/omp-par-scope.c | 47 +++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/gdb/testsuite/gdb.threads/omp-par-scope.c b/gdb/testsuite/gdb.threads/omp-par-scope.c
index 987fb34426..57b0beb7b6 100644
--- a/gdb/testsuite/gdb.threads/omp-par-scope.c
+++ b/gdb/testsuite/gdb.threads/omp-par-scope.c
@@ -18,6 +18,28 @@
 #include <stdio.h>
 #include <omp.h>
 
+omp_lock_t lock;
+omp_lock_t lock2;
+
+/* Enforce execution order between two threads using a lock.  */
+
+static void
+omp_set_lock_in_order (int num, omp_lock_t *lock)
+{
+  /* Ensure that thread num 0 first sets the lock.  */
+  if (num == 0)
+    omp_set_lock (lock);
+  #pragma omp barrier
+
+  /* Block thread num 1 until it can set the lock.  */
+  if (num == 1)
+    omp_set_lock (lock);
+
+  /* This bit here is guaranteed to be executed first by thread num 0, and
+     once thread num 0 unsets the lock, to be executed by thread num 1.  */
+  ;
+}
+
 /* Testcase for checking access to variables in a single / outer scope.
    Make sure that variables not referred to in the parallel section are
    accessible from the debugger.  */
@@ -31,6 +53,7 @@ single_scope (void)
 #pragma omp parallel num_threads (2) shared (s1, i1) private (s2, i2)
   {
     int thread_num = omp_get_thread_num ();
+    omp_set_lock_in_order (thread_num, &lock);
 
     s2 = 100 * (thread_num + 1) + 2;
     i2 = s2 + 10;
@@ -38,6 +61,8 @@ single_scope (void)
     #pragma omp critical
     printf ("single_scope: thread_num=%d, s1=%d, i1=%d, s2=%d, i2=%d\n",
 	    thread_num, s1, i1, s2, i2);
+
+    omp_unset_lock (&lock);
   }
 
   printf ("single_scope: s1=%d, s2=%d, s3=%d, i1=%d, i2=%d, i3=%d\n",
@@ -67,11 +92,15 @@ multi_scope (void)
 		     private (i21)
 	{
 	  int thread_num = omp_get_thread_num ();
+	  omp_set_lock_in_order (thread_num, &lock);
+
 	  i21 = 100 * (thread_num + 1) + 21;
 
 	  #pragma omp critical
 	  printf ("multi_scope: thread_num=%d, i01=%d, i11=%d, i21=%d\n",
 		  thread_num, i01, i11, i21);
+
+	  omp_unset_lock (&lock);
 	}
 
 	printf ("multi_scope: i01=%d, i02=%d, i11=%d, "
@@ -105,6 +134,7 @@ nested_func (void)
 #pragma omp parallel num_threads (2) shared (i, p, x) private (j, q, y)
       {
 	int tn = omp_get_thread_num ();
+	omp_set_lock_in_order (tn, &lock);
 
 	j = 1000 * (tn + 1);
 	q = j + 1;
@@ -112,6 +142,8 @@ nested_func (void)
 	#pragma omp critical
 	printf ("nested_func: tn=%d: i=%d, p=%d, x=%d, j=%d, q=%d, y=%d\n",
 		 tn, i, p, x, j, q, y);
+
+	omp_unset_lock (&lock);
       }
     }
   }
@@ -137,6 +169,8 @@ nested_parallel (void)
 #pragma omp parallel num_threads (2) private (l)
   {
     int num = omp_get_thread_num ();
+    omp_set_lock_in_order (num, &lock);
+
     int nthr = omp_get_num_threads ();
     int off = num * nthr;
     int k = off + 101;
@@ -144,23 +178,36 @@ nested_parallel (void)
 #pragma omp parallel num_threads (2) shared (num)
     {
       int inner_num = omp_get_thread_num ();
+      omp_set_lock_in_order (inner_num, &lock2);
+
       #pragma omp critical
       printf ("nested_parallel (inner threads): outer thread num = %d, thread num = %d\n", num, inner_num);
+
+      omp_unset_lock (&lock2);
     }
     #pragma omp critical
     printf ("nested_parallel (outer threads) %d: k = %d, l = %d\n", num, k, l);
+
+    omp_unset_lock (&lock);
   }
 }
 
 int
 main (int argc, char **argv)
 {
+  omp_init_lock (&lock);
+  omp_init_lock (&lock2);
+
   single_scope ();
   multi_scope ();
 #if HAVE_NESTED_FUNCTION_SUPPORT
   nested_func ();
 #endif
   nested_parallel ();
+
+  omp_destroy_lock (&lock);
+  omp_destroy_lock (&lock2);
+
   return 0;
 }
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [committed][gdb/testsuite] Stabilize execution order in omp-par-scope.c
  2020-07-20 12:42 [committed][gdb/testsuite] Stabilize execution order in omp-par-scope.c Tom de Vries
@ 2020-07-21  1:51 ` Kevin Buettner
  0 siblings, 0 replies; 2+ messages in thread
From: Kevin Buettner @ 2020-07-21  1:51 UTC (permalink / raw)
  To: gdb-patches

On Mon, 20 Jul 2020 14:42:28 +0200
Tom de Vries <tdevries@suse.de> wrote:

> Hi,
> 
> In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
> on omp_get_thread_num ().  Since execution order of the threads can vary from
> execution to execution, this can cause changes in test results.
> 
> F.i., we can see this difference between two test runs:
> ...
> -KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
> +PASS: single_scope: first thread: print i3
> -PASS: single_scope: second thread: print i3
> +KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
> ...
> In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
> that corresponds to the first thread executing that bit of code, and in the
> other case to the second thread.
> 
> Get rid of this difference by stabilizing execution order.
> 
> Tested on x86_64-linux.
> 
> Committed to trunk.

Thanks for doing this.

Kevin


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-07-21  1:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-20 12:42 [committed][gdb/testsuite] Stabilize execution order in omp-par-scope.c Tom de Vries
2020-07-21  1:51 ` Kevin Buettner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).