Rainer, thank you for looking it up.
Whether a certain implementation throws could depend on performance, tradition (on this platform), standard library philosophy, etc.
It would be difficult to decide that if on some platforms there is UB (when locking an already locked non-recursive mutex), then we should change C++ to call a do-not-resuscitate termination handler in that case on all platforms from now on.
As you said, for supporting implementations the standard already recommends that the specific condition can be specifically caught (throw a std::system_error with error condition resource_deadlock_would_occur).
So nothing more to do/improve here.
-----Ursprüngliche Nachricht-----
Von: Rainer Deyke via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: So 07.06.2026 10:20
Betreff: Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate
An: std-proposals@lists.isocpp.org;
CC: Rainer Deyke <rainerd@eldwood.com>;
On 6/7/26 01:58, Sebastian Wittmeier via Std-Proposals wrote:
> Is this truly UB (anything can go wrong, invalid program according to the standard, not just to the programmer's own rules) or a detected bug?
Disclaimer: I rely on https://cppreference.com/, not the actual text on
the standard. Quote from https://cppreference.com/:
If lock is called by a thread that already owns the mutex, the behavior
is undefined: for example, the program may deadlock. An implementation
that can detect the invalid usage is encouraged to throw a
std::system_error with error condition resource_deadlock_would_occur
instead of deadlocking.
This looks unambiguous to me. It is valid for the program to deadlock,
which is what must happen if the underlying implementation cannot (or
chooses not to) detect the deadlock. It is valid for the program to
throw. It is also valid for anything else to happen, because this is
undefined behavior, not unspecified behavior. It is valid to segfault.
It is valid to start mining bitcoins. It is valid for the program to
erase itself from disk. And it is valid for the program to leave itself
in an inconsistent state and then throw. Technically the entire
computer could be in an inconsistent state, not just the process.
Undefined behavior means all bets are off.
In practice, if you're writing non-portable code anyway and you know
that your specific C++ implementation throws on deadlock while leaving
the rest of the program in a consistent state, you can take advantage of
that knowledge. Just be aware that this may not work on any other C++
implementation. It's analogous to the way POSIX provides a whole bunch
of non-standard guarantees for C standard library functions that only
apply to POSIX environments.
--
Rainer Deyke - rainerd@eldwood.com
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals