On Sun, 7 Jun 2026, 03:06 Howard Hinnant via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I fully agree that in many situations a failed mutex lock is
> unrecoverable. You putting a noexcept specifier on the function that calls
> it is a good way to indicate that in your program.
>
> I vehemently disagree that in _all_ situations a failed mutex lock is
> unrecoverable. Some processes can not die without causing irreparable harm
> (physical, financial, whatever). A collection of threads may be working on
> a non-critial part of the process when contending for a failed lock.
> Perhaps logging? You don’t want your pacemaker to crash because a logging
> function failed. You want to cease logging except for creating an alert
> that maintenance is required.
>
> std::mutex needs to meet the needs of _all_ users, not just yours.
>
> You can make std::mutex do what you want with the minor amount of code you
> posted. The reverse is not true. If a process wants to take less drastic
> measures in the case of a failed mutex::lock, it can not do so if
> mutex::lock calls terminate(). A terminate handler can not avoid a program
> termination.
>

Or catch the system_error and rethrow your own lost_all_hope type that
tells the caller that what happened probably isn't recoverable and it
shouldn't try to do anything (if that's what makes sense for your
application).

We don't need changes in the standard to support this.




> Howard
>
> On Jun 6, 2026, at 2:03 PM, Frederick Virchanza Gotham via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > In my work this week, I submitted a pull request containing code like
> this:
> >
> > struct S {
> > optional<T> var;
> > void reset(void) noexcept
> > {
> > lock_guard mylock{some_global_mutex};
> > var.reset();
> > }
> > }
> >
> > The pull request went through code review, and a colleague of mine
> > responded to say:
> >
> > "You've marked that function 'noexcept' but 'mutex::lock' might throw"
> >
> > My response to him was:
> >
> > "If a mutex fails to lock, the entire process is fried"
> >
> > Mulling over this for a bit longer, I think that the Standard should
> > make a distinction between "normal exceptions" and "lost-all-hope
> > exceptions".
> >
> > For instance if you think a mutex might ever fail to lock in your
> > program, I think you should do something like the following:
> >
> > Step 1 - When the process starts, use 'std::fopen' to open a file on
> > disk for writing.
> > Step 2 - Invoke 'std::set_terminate_handler' to register a handler
> > that writes critical data to disk with 'std::fwrite', then
> > 'std::fclose', and then invokes 'std::_Exit' to immediately kill the
> > process.
> > Step 3 - Mark the aforementioned 'S::reset' method as 'noexcept', and
> > just let the terminate handler save critical data if 'mutex::lock'
> > throws.
> >
> > I don't think it's good enough that the Standard simply says that
> > 'mutex::lock' might throw 'std::system_error', reason being that this
> > isn't something you can just catch and recover from. If a mutex fails
> > to lock, you need to do one of the two following:
> >
> > Strategy 1 - Kill the entire process like I described above (i.e. let
> > the terminate handler save critical data and call 'std::_Exit').
> >
> > Strategy 2 - If not killing the entire process, at least mark a
> > portion of the program as unusable -- and this is where I would use a
> > "Do not resuscitate" flag (i.e. a DNR flag).
> >
> > A few years ago when I was programming security cameras in embedded
> > Linux, there was a background process that managed the mounting of an
> > encrypted volume. Sometimes the encrypted volume would spontaneously
> > unmount. We found that if you ever re-mounted the volume after it
> > spontaneously unmounted, you would get unreliable behaviour and data
> > corruption. For this reason I introduced a 'Do not resuscitate' flag.
> > If the encrypted volume were ever to spontaneously unmount, and as
> > soon as this was detected, the DNR flag would be set -- meaning that
> > the next time a script tried to mount the encrypted volume, the DNR
> > flag would forbid its re-mount. This strategy minimised data
> > corruption.
> >
> > I don't think C++ programmers should be accommodating the throwing of
> > 'std::system_error' from 'mutex::lock', for example by refraining from
> > marking 'S::reset' as 'noexcept'. Instead, C++ should have two
> > categories of exception -- normal exceptions and lost-all-hope
> > exceptions. So if you were to look up "mutex::lock" on
> > 'cppreference.com', instead of it saying:
> >
> > "Throws std::system_error when errors occur, including errors from the
> > underlying operating system that would prevent lock from meeting its
> > specifications. The mutex is not locked in the case of any exception
> > being thrown."
> >
> > Perhaps it would say something like:
> >
> > "Invokes the 'lost_all_hope' terminate handler when errors occur,
> > including errors from the underlying operating system that would
> > prevent lock from meeting its specifications."
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>