running TSAN with alternate pthread libraries

[Abcdefg Hijklmnop]

librtpi (https://gitlab.com/linux-rt/librtpi) is a library which implements condition variables and mutexes which function properly with the Linux kernel's realtime priority inheritance.    Except for a different function signature for condition variables and different defaults for mutexes, the library's implementation is similar to that of libpthread.  The subject has a long history (https://ossna2020.sched.com/event/cZIe/librtpi-conditional-variables-for-real-time-applications-gratian-crisan-national-instruments).

Compiling and running the library's self-tests with TSAN humorously results in output which flags data races on mutexes and condition variables themselves.     I'm posting here to inquire if anyone has experience running TSAN with alternate pthread libraries.   Or perhaps TSAN is tightly bound to libpthread and making it work properly with an alternate pthread implementation is a giant task?

Details are below.

Thanks,

Alison Chaiken

ali...@she-devel.com

--

$ git clone https://gitlab.com/linux-rt/librtpi.git

$ CC=clang CXX=clang++ CCXXFLAGS="$(CXXFLAGS) -std=c++17 -fsanitize=thread" CFLAGS="$(CFLAGS) -fsanitize=thread" LDFLAGS="-fsanitize=thread" ./configure

$ echo $TSAN_OPTIONS
external_symbolizer_path=/usr/bin/llvm-symbolizer-19

$ cd tests/glibc-tests

$ make tst-cond1
clang -DHAVE_CONFIG_H -I. -I../..  -I. -I../../src   -fsanitize=thread -MT tst-cond1.o -MD -MP -MF .deps/tst-cond1.Tpo -c -o tst-cond1.o tst-cond1.c
In file included from tst-cond1.c:90:
./test-driver.c:242:6: warning: comparison of function 'mallopt' not equal to a null pointer is always true [-Wtautological-pointer-compare]
  242 |         if (mallopt != NULL)
      |             ^~~~~~~    ~~~~
./test-driver.c:242:6: note: prefix with the address-of operator to silence this warning
  242 |         if (mallopt != NULL)
      |             ^
      |             &
1 warning generated.
mv -f .deps/tst-cond1.Tpo .deps/tst-cond1.Po
/bin/bash ../../libtool  --tag=CC   --mode=link clang  -fsanitize=thread  -fsanitize=thread -o tst-cond1 tst-cond1.o ../../src/librtpi.la -lpthread
libtool: link: clang -fsanitize=thread -fsanitize=thread -o .libs/tst-cond1 tst-cond1.o  ../../src/.libs/librtpi.so -lpthread

$ ./tst-cond1
&cond = 0x559d7f30fc00
&mut = 0x559d8067b800
parent: get mutex
parent: create child
parent: wait for condition
==================
WARNING: ThreadSanitizer: data race (pid=236420)
  Atomic write of size 4 at 0x559d8067b800 by main thread:
    #0 pi_mutex_unlock <null> (librtpi.so.1+0x1710) (BuildId: a18b93ee559eb7cfaa6a7f5fde33dc1b35d0a69b)
    #1 pi_cond_timedwait <null> (librtpi.so.1+0x1c3c) (BuildId: a18b93ee559eb7cfaa6a7f5fde33dc1b35d0a69b)
    #2 pi_cond_wait <null> (librtpi.so.1+0x1f99) (BuildId: a18b93ee559eb7cfaa6a7f5fde33dc1b35d0a69b)
    #3 do_test tst-cond1.c (tst-cond1+0xe6914) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #4 run_test_function tst-cond1.c (tst-cond1+0xe6e65) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #5 support_test_main tst-cond1.c (tst-cond1+0xe6ba7) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #6 main <null> (tst-cond1+0xe6837) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)

  Previous read of size 4 at 0x559d8067b800 by thread T1:
    #0 pi_mutex_trylock <null> (librtpi.so.1+0x14c7) (BuildId: a18b93ee559eb7cfaa6a7f5fde33dc1b35d0a69b)
    #1 pi_mutex_lock <null> (librtpi.so.1+0x1425) (BuildId: a18b93ee559eb7cfaa6a7f5fde33dc1b35d0a69b)
    #2 tf tst-cond1.c (tst-cond1+0xe6d68) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)

  Location is global 'mut' of size 64 at 0x559d8067b800 (tst-cond1+0x1493800)

  Thread T1 (tid=236423, running) created by main thread at:
    #0 pthread_create <null> (tst-cond1+0x62e45) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #1 do_test tst-cond1.c (tst-cond1+0xe68d6) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #2 run_test_function tst-cond1.c (tst-cond1+0xe6e65) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #3 support_test_main tst-cond1.c (tst-cond1+0xe6ba7) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)
    #4 main <null> (tst-cond1+0xe6837) (BuildId: 61b8eace3e8c3a623f537ffb95d7cf7ff933decd)

SUMMARY: ThreadSanitizer: data race (/home/alison/gitsrc/librtpi/src/.libs/librtpi.so.1+0x1710) (BuildId: a18b93ee559eb7cfaa6a7f5fde33dc1b35d0a69b) in pi_mutex_unlock
==================
child: got mutex; signalling

[Dmitry Vyukov]

On Sat, 22 Feb 2025 at 23:19, Abcdefg Hijklmnop
<donoteve...@gmail.com> wrote:
>
> librtpi (https://gitlab.com/linux-rt/librtpi) is a library which implements condition variables and mutexes which function properly with the Linux kernel's realtime priority inheritance. Except for a different function signature for condition variables and different defaults for mutexes, the library's implementation is similar to that of libpthread. The subject has a long history (https://ossna2020.sched.com/event/cZIe/librtpi-conditional-variables-for-real-time-applications-gratian-crisan-national-instruments).
>
> Compiling and running the library's self-tests with TSAN humorously results in output which flags data races on mutexes and condition variables themselves. I'm posting here to inquire if anyone has experience running TSAN with alternate pthread libraries. Or perhaps TSAN is tightly bound to libpthread and making it work properly with an alternate pthread implementation is a giant task?

Hi Abcdefg,

This looks just like a bug in that library.