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
