[PATCH] Fix test-case on ppc64le (PR testsuite/79455).

[Martin Liška]

Received as HTML from Kelvin:

I have reviewed some of the implementation details for pthread_mutex_init and pthread_mutex_lock, and have confirmed that ppc64 does use memset to initialize the entirety of its mutex lock structure before potentially overwriting a few of its fields with non-zero data.  So in this regard, your fix seems appropriate.

However, I'm confused about how this program runs.  My understanding of the test case code is that the use of barrier_wait() calls is supposed to force Thread1 to run "to completion" before Thread2 even starts.  So if my understanding is correct, it is not sensible for Thread1's pthread_mutex_init call to be followed "immediately" by Thread2's pthread_mutex_lock() call.

The comment in tsan_barrier.h describes barrier_init and barrier_wait as "TSAN-invisible barriers".  Can you help me understand how TSAN works in this regard?  I was expecting that TSAN runs the program with instrumentation on the TSAN-visible "thread services" but no instrumentation on the TSAN-invisible thread services.  Is this understanding correct?

The questions I am trying to answer for myself are whether this test, as crafted, is really sufficiently "portable" and "meaningful".  It seems to be making non-portable assumptions about the implementation of pthread_mutex_init and pthread_mutex_lock and pthread_mutex_unlock, even with the proposed change.

Just to clarify:
  Is it your understanding that the expected tsan diagnostic report is complaining that some data field of the mutex structure is being read in Thread 2 after having been written in Thread 1 without any "happens before" relationship (since tsan cannot see the barrier_wait calls?)  Since the "conflict" is going all the way back to Thread 1's pthread_mutex_init call, am I correct in my understanding that the "first conflict noticed" is dealing with some part of the lock structure that is not normally modified by the execution of pthread_mutex_lock and pthread_mutex_unlock.

Maybe adding a comment or two to the test case to clarify what is being tested would be most helpful here...