[all-commits] [llvm/llvm-project] e6de45: [tsan] Don't treat uncontended pthread_once as a p...

[David Benjamin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e6de45a22933114a1d9421dad558a3d62546cb53
      https://github.com/llvm/llvm-project/commit/e6de45a22933114a1d9421dad558a3d62546cb53
  Author: David Benjamin <davidben at google.com>
  Date:   2025-03-24 (Mon, 24 Mar 2025)

  Changed paths:
    M compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
    M compiler-rt/test/tsan/cxa_guard_acquire.cpp

  Log Message:
  -----------
  [tsan] Don't treat uncontended pthread_once as a potentially blocking region (#132477)

guard_acquire is a helper function used to implement TSan's
__cxa_guard_acquire and pthread_once interceptors.
https://reviews.llvm.org/D54664 introduced optional hooks to support
cooperative multi-threading. It worked by marking the entire
guard_acquire call as a potentially blocking region.

In principle, only the contended case needs to be a potentially blocking
region. This didn't matter for __cxa_guard_acquire because the compiler
emits an inline fast path before calling __cxa_guard_acquire. That is,
once we call __cxa_guard_acquire at all, we know we're in the contended
case.

https://reviews.llvm.org/D107359 then unified the __cxa_guard_acquire
and pthread_once interceptors, adding the hooks to pthread_once.
However, unlike __cxa_guard_acquire, pthread_once callers are not
expected to have an inline fast path. The fast path is inside the
function.

As a result, TSan unnecessarily calls into the cooperative
multi-threading engine on every pthread_once call, despite applications
generally expecting pthread_once to be fast after initialization. Fix
this by deferring the hooks to the contended case inside guard_acquire.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications