Re: [RFC] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer

[Jonathan Wakely <jwakely@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

On Thu, 11 May 2023 at 16:54, Thomas Rodgers <trodgers@redhat.com> wrote:

>
>
> On Thu, May 11, 2023 at 5:21 AM Mike Crowe via Libstdc++ <
> libstdc++@gcc.gnu.org> wrote:
>
>> On Wednesday 10 May 2023 at 12:31:12 +0100, Jonathan Wakely wrote:
>> > On Wed, 10 May 2023 at 12:20, Jonathan Wakely via Libstdc++ <
>> > libstdc++@gcc.gnu.org> wrote:
>> >
>> > > This patch would avoid TSan false positives when using timed waiting
>> > > functions on mutexes and condvars, but as noted below, it changes the
>> > > semantics.
>> > >
>> > > I'm not sure whether we want this workaround in place until tsan gets
>> > > fixed.
>> > >
>> > > On one hand, there's no guarantee that those functions use the right
>> > > clock anyway (and they won't do unless a recent-ish glibc is used).
>> But
>> > > on the other hand, if they normally would use the right clock because
>> > > you have glibc support, it's not ideal for tsan to cause a different
>> > > clock to be used.
>> > >
>> >
>> > But of course, it's not ideal to get false positives from tsan either
>> > (especially when it looks like a libstdc++ bug, as initially reported to
>> > me).
>>
>> I think that this is probably the least-worst option in the short term. As
>> TSan is distributed with GCC this workaround can be removed as soon as its
>> TSan implementation gains the necessary interceptors. I shall look into
>> trying to do that.
>>
>>
> I don't have a strong opinion either way on this, but I think documenting
> the TSAN suppressions is the option most in keeping with the principle of
> Least Astonishment.
>

That assumes anybody reads the docs :-)
Getting TSan errors from the std::lib is somewhat astonishing. The errors
could be avoided, at the risk of subtle timing differences between
tsanitized and un-tsanitized builds ... but won't there be subtle diffs
anyway based on the TSan overhead? Admittedly those will just be fairly
constant overhead, and so immune to system clock adjustments.