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

2023-05-11 Thread Jonathan Wakely via Gcc-patches
On Thu, 11 May 2023 at 16:54, Thomas Rodgers wrote: > > > On Thu, May 11, 2023 at 5:21 AM Mike Crowe via Libstdc++ < > libstd...@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++ < >> > libs

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

2023-05-11 Thread Thomas Rodgers via Gcc-patches
On Thu, May 11, 2023 at 5:21 AM Mike Crowe via Libstdc++ < libstd...@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++ < > > libstd...@gcc.gnu.org> wrote: > > > > > This patch would avoid TSan fa

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

2023-05-11 Thread Jonathan Wakely via Gcc-patches
On Thu, 11 May 2023 at 13:19, Mike Crowe 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++ < > > libstd...@gcc.gnu.org> wrote: > > > > > This patch would avoid TSan false positives when using timed waiting >

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

2023-05-11 Thread Mike Crowe via Gcc-patches
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++ < > libstd...@gcc.gnu.org> wrote: > > > This patch would avoid TSan false positives when using timed waiting > > functions on mutexes and condvars, but as noted below, i

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

2023-05-10 Thread Jonathan Wakely via Gcc-patches
On Wed, 10 May 2023 at 12:20, Jonathan Wakely via Libstdc++ < libstd...@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 i