LWG-2309 mutex::lock() should not throw device_or_resource_busy

[StephanTLavavej]

LWG-2309 mutex::lock() should not throw device_or_resource_busy

This was fixed in our "WCFB02" vNext branch (which needs to be ported to git).

[BillyONeal]

We only throw this if someone locks a recursive mutex more than UINT_MAX times. The SG1 discussion suggests that that case should terminate, but I don't see the corresponding changes to do that in the LWG issue report. I'll ask.

[AlexGuteniev]

working draft still says to throw:
http://eel.is/c++draft/thread.mutex#recursive-3

If a thread has already acquired the maximum level of ownership for a recursive_­mutex object, additional calls to try_­lock() fail, and additional calls to lock() throw an exception of type system_­error.

[AlexGuteniev]

To me it is still a bug in the Standard

• This http://eel.is/c++draft/thread.mutex.requirements.mutex#13 doesn't apply, since it is recursive_mutex.
• Falling back to this http://eel.is/c++draft/thread.mutex.requirements.mutex#4
• Still neither of the mentioned fits the situation

[AlexGuteniev]

Possibly it could be resolved the same way as with latch/semaphore/barrier -- expose constexpr ptrdiff_t max() andUB if overrun

[BillyONeal]

To me it is still a bug in the Standard

• Falling back to this http://eel.is/c++draft/thread.mutex.requirements.mutex#4
• Still neither of the mentioned fits the situation

For mutex (rather than recursive_mutex) it is a precondition violation so we can do whatever we want, including the throw that we currently do. But I think abort would be better. http://eel.is/c++draft/thread.mutex.requirements#mutex-7

[frederick-vs-ja]

We only throw this if someone locks a recursive mutex more than UINT_MAX times. The SG1 discussion suggests that that case should terminate, but I don't see the corresponding changes to do that in the LWG issue report. I'll ask.

Is this right? During my local tests, even a recursive_mutex is locked more than UINT_MAX times, no exception is thrown yet.

Control flow eventually goes here when mutex::lock/recursive_mutex::lock is called.

STL/stl/src/mutex.cpp

Lines 97 to 104 in 73924c1

	int res = WAIT_TIMEOUT;
	if (target == nullptr) { // no target --> plain wait (i.e. infinite timeout)
	if (mtx->thread_id != static_cast<long>(GetCurrentThreadId())) {
	mtx->_get_cs()->lock();
	}
	res = WAIT_OBJECT_0;

For recursive_mutex::lock, res would never be set to WAIT_TIMEOUT.

STL/stl/src/mutex.cpp

Lines 133 to 142 in 73924c1

	if (res == WAIT_OBJECT_0 || res == WAIT_ABANDONED) {
	if (1 < ++mtx->count) { // check count
	if ((mtx->type & _Mtx_recursive) != _Mtx_recursive) { // not recursive, fixup count
	--mtx->count;
	res = WAIT_TIMEOUT;
	}
	} else {
	mtx->thread_id = static_cast<long>(GetCurrentThreadId());
	}
	}

So _Mtx_lock always return _Thrd_success for recursive_mutex, although sometimes UB is triggered due to overflowing int.

---

Edit: Oh, I misunderstood the meaning. recursive_timed_mutex::lock correctly (per currently wording) throws, while recursive_mutex::lock never reports failure and may trigger UB.