6

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?

Johan Bezem
  • 2,582
  • 1
  • 20
  • 47
ninjalj
  • 42,493
  • 9
  • 106
  • 148

2 Answers2

11

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.....)

Anthony Williams
  • 66,628
  • 14
  • 133
  • 155
1
  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.
Alan
  • 143
  • 1
  • 6