thrd_busy and mtx_lock()/mtx_timedlock()

问题:

I have the following questions about C1x mutexes (§7.25.4):

In which situations can mtx_lock() return thrd_busy instead of blocking? In which situations can mtx_timedlock() return thrd_busy?

Note that thrd_busy is defined in §7.25.1 ¶5 as being returned "when a resource requested by a test and return function is already in use".

I would expect thrd_busy to be only returned by mtx_trylock(), or at most also by mtx_lock() when invoked with a mtx_try or mtx_try | mtx_recursive mutex, but definitely not from mtx_timedlock(), which requires a mutex which supports timeout, i.e. a mtx_timed or mtx_timed | mtx_recursive mutex.

Is this just and oversight in the draft? Or am I missing something?

回答1:

If the mutex is not recursive, but you try to lock it in a recursive manner then the behaviour is undefined. However, an implementation could detect this and return thrd_busy. (Alternatively, it may block forever, or return thrd_error, or thrd_success, or format your hard disk.....)

回答2:

1. mtx_lock() does not return thrd_busy, however, the mtx_trylock function returns thrd_busy if the resource requested is already in use.
2. mtx_timedlock() does not return thrd_busy. The mtx_timedlock function returns thrd_success on success, or thrd_timedout if the time specified was reached without acquiring the requested resource, or thrd_errorif the request could not be honored.