public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Brown <julian@codesourcery.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: Jakub Jelinek <jakub@redhat.com>, <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 0/4] openacc: Async fixes
Date: Fri, 2 Jul 2021 14:51:51 +0100	[thread overview]
Message-ID: <20210702145151.0d6a5371@squid.athome> (raw)
In-Reply-To: <20210630114033.4e85103f@squid.athome>

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

On Wed, 30 Jun 2021 11:40:33 +0100
Julian Brown <julian@codesourcery.com> wrote:

> On Wed, 30 Jun 2021 10:28:00 +0200
> Thomas Schwinge <thomas@codesourcery.com> wrote:
> 
> > >  - The OpenACC profiling-interface implementation did not measure
> > >    asynchronous operations properly.    
> > 
> > We'll need to be careful: (possibly, an older version of) that one
> > we internally had identified to be causing some issues; see the
> > "acc_prof-parallel-1.c intermittent failure on og10 branch" emails,
> > 2020-07.  
> 
> Hmm, I'll check those.

The problem here is that the async callbacks now execute in a different
thread to the main program, so the direct sharing of the 'state'
variable isn't safe. (I verified that by observing the
result of "pthread_self ()" calls from the main thread and from the
callback.)

The attached patch appears to make the test run reliably on mainline
(which still exhibits the failure with the parent patch series, very
intermittently). A better solution might be to use the memory-model
builtins for all 'state' variable accesses though.

I think the async profiling callbacks *have to* run in a different
thread to the main program, which would make this a testcase bug (the
spec doesn't explicitly say this as of 3.0 though). However there might
be an argument for making "acc_wait" and friends thread barriers with
respect to the host (i.e. calling __atomic_thread_fence in the
appropriate place in libgomp) -- otherwise you have "break out of the
abstraction" provided by OpenACC and rely on a non-OpenACC API in order
to observe any results measured in the async profiling callbacks. OTOH
the memory-model stuff is part of C now, so maybe that's fine (and also,
I'm doubtful that just adding the barrier and using regular global
variable accesses is sufficient to ensure thread safety anyway).

Thoughts?

Thanks,

Julian

[-- Attachment #2: acc_prof-parallel-barrier-1.diff --]
[-- Type: text/x-patch, Size: 679 bytes --]

commit a24d5c521b66ae88d0ddd05ce7fe247c94802595
Author: Julian Brown <julian@codesourcery.com>
Date:   Fri Jul 2 03:42:41 2021 -0700

    Add barrier, hack

diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c
index 9c8af743aba..2bba7bd2e55 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c
@@ -683,6 +683,7 @@ int main()
       state_init = state;
     }
 #pragma acc wait
+   __atomic_thread_fence (__ATOMIC_SEQ_CST);
     assert (state_init == 104);
   }
   assert (state == 108);

  reply	other threads:[~2021-07-02 13:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 23:42 Julian Brown
2021-06-29 23:42 ` [PATCH 1/4] openacc: Async fix for lib-94 testcase Julian Brown
2021-06-29 23:42 ` [PATCH 2/4] openacc: Fix async bugs in several OpenACC test cases Julian Brown
2021-06-29 23:52   ` Julian Brown
2021-06-29 23:42 ` [PATCH 3/4] openacc: Fix asynchronous host-to-device copies in libgomp runtime Julian Brown
2021-07-27 10:01   ` Thomas Schwinge
2023-03-10 15:22     ` Allow libgomp 'cbuf' buffering with OpenACC 'async' for 'ephemeral' data (was: [PATCH 3/4] openacc: Fix asynchronous host-to-device copies in libgomp runtime) Thomas Schwinge
2021-06-29 23:42 ` [PATCH 4/4] openacc: Profiling-interface fixes for asynchronous operations Julian Brown
2021-06-30  8:28 ` [PATCH 0/4] openacc: Async fixes Thomas Schwinge
2021-06-30 10:40   ` Julian Brown
2021-07-02 13:51     ` Julian Brown [this message]
2023-03-10 11:38   ` Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210702145151.0d6a5371@squid.athome \
    --to=julian@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=thomas@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).