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_at_[hidden]> Gesendet:So 07.06.2026 10:20 Betreff:Re: [std-proposals] Exceptions : lost all hope -- do not resuscitate An:std-proposals_at_[hidden]; CC:Rainer Deyke <rainerd_at_[hidden]>; 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_at_[hidden] -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals