[Bug libgomp/50175] New: data race with barrier

[Bug libgomp/50175] New: data race with barrier

[Joost.VandeVondele at pci dot uzh.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175

             Bug #: 50175
           Summary: data race with barrier
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Joost.VandeVondele@pci.uzh.ch


I'm using valgrind together with the drd tool to find data races in my OMPed
code. However, one warning traces back to libgomp, as illustrated by the simple
test program below. As instructed in the drd manual, gcc has been configured
with --disable-linux-futex 

Note also that the warning only happens with 3 or more threads.

> cat test.f90
 !$OMP PARALLEL
 !$OMP BARRIER
 !$OMP END PARALLEL
END

> gfortran  -fopenmp test.f90
> export OMP_NUM_THREADS=3
> valgrind --tool=drd ./a.out
==12681== drd, a thread error detector
==12681== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
==12681== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==12681== Command: ./a.out
==12681==
==12681== Conflicting store by thread 1 at 0x0618c28c size 4
==12681==    at 0x53B297D: gomp_team_barrier_wait (bar.h:66)
==12681==    by 0x53B1D2E: gomp_team_end (team.c:464)
==12681==    by 0x40072A: MAIN__ (in /data03/vondele/bugs/a.out)
==12681==    by 0x400760: main (in /data03/vondele/bugs/a.out)
==12681== Address 0x618c28c is at offset 236 from 0x618c1a0. Allocation
context:
==12681==    at 0x4C29301: malloc (vg_replace_malloc.c:236)
==12681==    by 0x53AD018: gomp_malloc (alloc.c:36)
==12681==    by 0x53B165C: gomp_new_team (team.c:144)
==12681==    by 0x53B078B: GOMP_parallel_start (parallel.c:108)
==12681==    by 0x40071B: MAIN__ (in /data03/vondele/bugs/a.out)
==12681==    by 0x400760: main (in /data03/vondele/bugs/a.out)
==12681== Other segment start (thread 2)
==12681==    at 0x4C31759: sem_wait (drd_pthread_intercepts.c:1010)
==12681==    by 0x53B265B: gomp_sem_wait (sem.c:120)
==12681==    by 0x53B28DB: gomp_team_barrier_wait_end (bar.c:146)
==12681==    by 0x400778: MAIN__._omp_fn.0 (in /data03/vondele/bugs/a.out)
==12681==    by 0x53B159F: gomp_thread_start (team.c:115)
==12681==    by 0x4C295F0: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281)
==12681==    by 0x5A09A4E: start_thread (in /lib64/libpthread-2.11.2.so)
==12681==    by 0x5CF082C: clone (in /lib64/libc-2.11.2.so)
==12681== Other segment end (thread 2)
==12681==    at 0x5A10EB4: __lll_lock_wait (in /lib64/libpthread-2.11.2.so)
==12681==    by 0x5A0C2A3: _L_lock_999 (in /lib64/libpthread-2.11.2.so)
==12681==    by 0x5A0C0B8: pthread_mutex_lock (in /lib64/libpthread-2.11.2.so)
==12681==    by 0x4C2B7B4: pthread_mutex_lock (drd_pthread_intercepts.c:586)
==12681==    by 0x53B2968: gomp_team_barrier_wait (mutex.h:44)
==12681==    by 0x53B15AB: gomp_thread_start (team.c:116)
==12681==    by 0x4C295F0: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281)
==12681==    by 0x5A09A4E: start_thread (in /lib64/libpthread-2.11.2.so)
==12681==    by 0x5CF082C: clone (in /lib64/libc-2.11.2.so)
==12681==
==12681==
==12681== For counts of detected and suppressed errors, rerun with: -v
==12681== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 31)

[Bug libgomp/50175] data race with OMP barrier

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-24 14:55:18 UTC ---
If this is about bar->arrived writes, then I don't see any races.
During the lifetime of a barrier, in the first phase arrived is incremented by
each thread, guarded by bar->mutex1 lock.  The threads then unlock bar->mutex1
lock, except for the last thread which keeps it locked and decrements
bar->arrived again, then, still with bar->mutex1 locked wakes up all the other
threads which then either atomically, or guarded with bar->mutex2 lock,
decrement bar->arrived again.  The last of those threads then posts to
bar->sem2
semaphore on which the thread holding bar->mutex1 is waiting before unlocking
that lock.  Thus, I don't see how the first phase (where bar->arrived
adjustments are done guarded with bar->mutex1 lock) can overlap with the second
phase (where it is decremented atomically or with mutex2).  Not even the second
phase with following first phase.  Thus I think valgrind is wrong about this.

CCing rth as author...

[Bug libgomp/50175] data race with OMP barrier

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch
         Resolution|                            |DUPLICATE

--- Comment #2 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2013-03-29 09:11:10 UTC ---
This is at best a dup of PR40362, and likely fixed for the linux futex version
as 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c38

*** This bug has been marked as a duplicate of bug 40362 ***