Thrd_busy and mtx_lock () / mtx_timedlock ()

I have the following questions about C1-muxes (§7.25.4):

In what situations can mtx_lock() return thrd_busy instead of locking? In what situations mtx_timedlock() return thrd_busy ?

Note that thrd_busy is defined in §7.25.1 ¶5 as being returned “when the resource requested by the check and return function is already in use”.

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

Is this fair and oversight in the project? Or am I missing something?

+4
c multithreading c11 mutex
source share
2 answers

If the mutex is not recursive, but you are trying to lock it in a recursive manner, then the behavior is undefined. However, an implementation can detect this and return thrd_busy . (Alternatively, it can block forever or return thrd_error or thrd_success or format the hard drive .....)

+5
source share
  • mtx_lock () does not return thrd_busy, however, the mtx_trylock function returns thrd_busy if the requested resource is already in use.
  • mtx_timedlock () does not return thrd_busy. The mtx_timedlock function returns thrd_success on success or thrd_timedout if the specified time was reached without receiving the requested resource, or thrd_errorif the request could not be completed.
+1
source share

All Articles