[libcxx-commits] [PATCH] D110349: [libcxx][SystemZ][z/OS] Added is_threading_api_enabled and might_have_multiple_threads to __threading_support

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D110349#3116828 <https://reviews.llvm.org/D110349#3116828>, @DanielMcIntosh-IBM wrote:

> In D110349#3116616 <https://reviews.llvm.org/D110349#3116616>, @ldionne wrote:
>
>> Is there a reason why the underlying C library can't implement e.g. `mtx_lock` as a no-op if threading is disabled at runtime?
>
> I don't know if we could have the underlying `pthread_mutex_lock` and friends act as a no-op like you've described (it's managed by a separate team), but I strongly suspect it's not an option, as that could affect the behaviour of existing applications on z/OS.

I don't understand -- if it's correct to do it for libc++, it should be correct to do it for the C library too, no? If a program is single-threaded, I don't understand why the C library couldn't apply the same optimizations that you're trying to add to libc++, i.e. make mutexes no-ops and so on.

> However, making `__libcpp_mutex_lock` a no-op when the POSIX functions aren't available (aka `POSIX(OFF)`) might be an option, and it might work for some of the places we are making changes, but it won't work for all of them.
> For example, it won't work for D113054 <https://reviews.llvm.org/D113054>. In `POSIX(OFF)`, not only does `pthread_once` (and thus __libcpp_execute_once) not work, there's no way of allocating thread-local storage, so we'd have to implement fake versions of `__libcpp_execute_once` and all the thread local storage functions. That would still be technically feasible, but it would get very ugly very fast, and probably perform exceedingly poorly.

There is actually a way to use an external threading API to implement all the libc++ threading primitives, see `_LIBCPP_HAS_THREAD_API_EXTERNAL`. We could promote it to official support if that were helpful, but I'd still like to understand why an optimization that is valid for libc++ isn't valid for libc, i.e. my question above.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110349/new/

https://reviews.llvm.org/D110349