1

mutex operations could result in exceptions with the following mutex error codes:

  1. resource_deadlock_would_occur
  2. resource_unavailable_try_again
  3. operation_not_permitted
  4. device_or_resource_busy
  5. invalid_argument

I have tried 2 situations:

  1. a deadlock : which should result in an exception with the resource_deadlock_would_occur error code.
  2. trying to lock a mutex twice : which should result in an exception with the device_or_resource_busy error code.

Both programs are from Stroustrup's book.

Neither situation results in a exception. Both programs simply end without an exception or error message, perhaps due to a timeout.

Josuttis states that in case of a deadlock, the standard library permits (but doesn't require) an exception to be thrown.

Further, according to this thread, trying to lock a mutex twice might also not cause an exception to be thrown. Evidently, the standard library treats this as "undefined behavior" and leaves it to the implementation to decide.

So, are the other three error codes (resource_unavailable_try_again, operation_not_permitted, invalid_argument) also treated as "undefined behavior"?

If an exception isn't guaranteed in these situations, then how can the program protect itself at run-time, against this error?

I haven't been able to find any online documentation on this aspect, and hence this query.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
SSteven
  • 733
  • 5
  • 17
  • 3
    *"a deadlock : which should result in an exception"* Not should, but [may](http://en.cppreference.com/w/cpp/thread/mutex/lock): "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." – Igor Tandetnik Apr 25 '18 at 14:06
  • 2
    are you talking about `std::mutex` ? .... well reading your links I know the answer, nevertheless imho you should mention it in the question (and imho also code should be included in the question) – 463035818_is_not_an_ai Apr 25 '18 at 14:08
  • 3
    *"how can the program protect itself at run-time, against this error"* The same way you deal with any other bug - testing and debugging. – Igor Tandetnik Apr 25 '18 at 14:09
  • 1
    Re, "deadlock...should result in an exception..." [Documentation for `std::mutex`](http://en.cppreference.com/w/cpp/thread/mutex/lock) does not agree with that statement. A general purpose deadlock-detection mechanism would be costly, and most applications can be designed so that they don't need it. `std::mutex` defines a minimal API that can be implemented on most operating systems/hardware platforms. If you want something more sophisticated, you either must build your own on top of `std::mutex`, or use somebody else's library code that does the same. – Solomon Slow Apr 25 '18 at 14:56
  • 1
    Re, "the standard library treats this as 'undefined behavior' and leaves it to the implementation..." Undefined behavior is not the same thing as _implementation-specified behavior_ or _unspecified behavior_. https://stackoverflow.com/a/4105123/801894 When the standard says "implementation-specified" or "unspecified," then you may expect behavior that is reasonable and appropriate for the OS/platform on which your code runs. When the standard says "undefined," all bets are off. You have no right to expect anything at all if your program invokes UB. – Solomon Slow Apr 25 '18 at 15:07

0 Answers0