This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix test-case on ppc64le (PR testsuite/79455).
On 04/26/2017 12:05 PM, Martin Liška wrote:
> 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...
>
Well, I'm not the author neither of original test-case or modifications that added tsan_barrier.h.
I'm CCing Bernd that can hopefully answer your questions.
Martin