Re: [Valgrind-developers] false positive in helgrind with cond_wait/cond_signal (?)

[Konstantin S. <kon...@gm...>]

>> As far as I understand, helgrind is not more than just Eraser :)
helgrind is more than just Eraser :)

On Dec 5, 2007 3:16 PM, Konstantin Serebryany <
kon...@gm...> wrote:

> As far as I understand, helgrind is not more than just Eraser :)
>
> For example, the following program does not report any race, while GLOB is
> *not* protected by any lock.
>
> % cat cv2.cc
> #define _MULTI_THREADED
> #include <pthread.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> static int                 COND = 0;
> static int                 GLOB = 0;
> static pthread_cond_t      CV = PTHREAD_COND_INITIALIZER;
> static pthread_mutex_t     MU = PTHREAD_MUTEX_INITIALIZER;
>
> void *run_pm(void*) {
>   sleep(2); // we want waiter to get there first
>   GLOB = 1;
>   pthread_mutex_lock(&MU);
>     COND++;
>     fprintf(stderr, "Signal: COND: %d\n", COND);
>     pthread_cond_signal(&CV);
>   pthread_mutex_unlock(&MU);
>   return NULL;
> }
>
> int main() {
>   pthread_t             threadid;
>   GLOB = 2;
>   pthread_create(&threadid, NULL, run_pm, NULL);
>
>   pthread_mutex_lock(&MU);
>     while (COND != 1) {
>       pthread_cond_wait(&CV, &MU);
>     }
>   pthread_mutex_unlock(&MU);
>
>   GLOB = 2;
>   fprintf(stderr, "GLOB: %d\n", GLOB);
>   pthread_join(threadid, NULL);
>   return 0;
> }
> % g++ -g  cv2.cc -lpthread ; ~/race/valgrind32orig/Inst/bin/valgrind -q
> --tool=helgrind ./a.out
> Signal: COND: 1
> GLOB: 2
> %
>
>
>
> On Dec 5, 2007 3:10 PM, Bart Van Assche <bar...@gm...> wrote:
>
> > On Dec 5, 2007 10:56 AM, Konstantin Serebryany <
> > kon...@gm...> wrote:
> >
> > > Hi Julian, all,
> > >
> > > I get a report about a race from helgrind, while everything looks well
> > > synchronized to me.
> > > Am I wrong?
> > >
> >
> > I can be wrong, but my understanding is that the Eraser algorithm
> > (helgrind) reports any conflicting accesses to shared variables that are not
> > protected by proper locking, so I expect helgrind to complain on the last
> > COND access. DRD on the other hand looks for possible causes of
> > nondeterminism. There are no such issues in the program cv.cc, hence DRD
> > does not complain on any of the COND accesses in cv.cc.
> >
> > Regards,
> >
> > Bart Van Assche.
>
>
>