[PATCH] D29588: Use rw locks for sanitizer thread registry

[Francis Ricci via Phabricator via llvm-commits]

fjricci added a comment.

In https://reviews.llvm.org/D29588#669786, @dvyukov wrote:

> In https://reviews.llvm.org/D29588#669125, @fjricci wrote:
>
> > In https://reviews.llvm.org/D29588#668828, @dvyukov wrote:
> >
> > > > Sharing a mutex access across threads like this is not supported by blocking mutex
> > >
> > > Why?
> >
> >
> > If a thread owns a mutex on the thread registry for writing (as with a blocking mutex), we can't really assume in another thread that the registry won't change. Since the thread accessing the data is actually in a separate process (the result of a clone() in StopTheWorld), I'm not sure that there's even a way to pass the blocking mutex around safely.
> >
> > > I've checked BlockingMutex comments and linux/mac/win implementation. I don't see any indication that it's not supported.
> > >  How is RWMutex different?
> >
> > An RWMutex acquired for read-only use can be safely used for reads by multiple threads, as it guarantees the protected data won't change. A blocking mutex provides no guarantees that the protected state won't change (and in fact implies that it probably will).
>
>
> Sorry, I am not following you.
>  How can protected data change when a thread holds the mutex and is not changing the data? Who/how can change the data?
>  Whoever wants to change the data must acquire the mutex first, but it won't because the parent process holds the mutex.
>  What do you mean y "passing blocking mutex around"? And why do we need to do it?
>
> The parent process holds the mutex thus ensuring that  nobody else is changing the data.


Correct. We know that the data won't change in this particular case, because we know the parent isn't changing the data, and we know that our parent is holding the lock. However, this isn't what CheckLocked() is checking. CheckLocked() checks that *any* thread holds the lock, it doesn't need to be our parent to pass the check. That thread which is holding the lock could very well be changing the data. Even our parent could, in theory, be changing the data.


https://reviews.llvm.org/D29588