[Bug libstdc++/108836] New: std::mutex disappears in single-threaded libstdc++ builds

[Bug libstdc++/108836] New: std::mutex disappears in single-threaded libstdc++ builds

[pdimov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836

            Bug ID: 108836
           Summary: std::mutex disappears in single-threaded libstdc++
                    builds
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdimov at gmail dot com
  Target Milestone: ---

We've been getting reports in Boost that our uses of <mutex> and std::mutex
don't work in a single-threaded build of libstdc++, so we had to add
configuration macros to avoid these issues. One example is
https://github.com/boostorg/system/commit/53c00841fc0d892bf43cda60e3ea2f05c4362b32,
another https://github.com/boostorg/url/issues/684.

Is there a reason not to make std::mutex available in single threaded builds,
with its operations being no-ops?

[Bug libstdc++/108836] std::mutex disappears in single-threaded libstdc++ builds

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
mingw32 is no longer defaults to a single threaded and std::mutex is supported
there on the trunk for GCC 13 ....

[Bug libstdc++/108836] std::mutex disappears in single-threaded libstdc++ builds

[pdimov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836

--- Comment #2 from Peter Dimov <pdimov at gmail dot com> ---
That's good to hear, but I don't think the issue is specific to mingw32. The
other report, https://github.com/boostorg/system/issues/92, was about "B&R
PLC", whatever this means. :-)

[Bug libstdc++/108836] std::mutex disappears in single-threaded libstdc++ builds

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Whatever we do it won't help them, as they're using libstdc++ headers from gcc
6.3

It's possible to have a gcc build that has limited support for threading, but
not enough to support C++11 std::mutex, std::thread etc and in such cases it
would be odd to have a no-op mutex. Another option might be to provide a very
dumb mutex using atomic_flag for a spin lock.

[Bug libstdc++/108836] std::mutex disappears in single-threaded libstdc++ builds

[pdimov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836

--- Comment #4 from Peter Dimov <pdimov at gmail dot com> ---
A compromise between no mutex at all, and a mutex that is silently a no-op,
could be a no-op mutex with [[deprecated]] members, although the atomic_flag is
probably better.