thrd_busy 和 mtx_lock()/mtx_timedlock()
我对 C1x 互斥体有以下问题 (§7.25.4)：
在哪些情况下 mtx_lock() 可以返回 thrd_busy 而不是阻塞？在什么情况下mtx_timedlock()可以返回thrd_busy？
请注意，thrd_busy 在 §7.25.1 ¶5 中定义为“当测试和返回函数请求的资源已在使用时”返回。
我希望 thrd_busy 仅由 mtx_trylock() 返回，或者最多也由 mtx_lock() 在使用 mtx_try 调用时返回 或 mtx_try | mtx_recursive 互斥体，但绝对不是来自 mtx_timedlock()，它需要一个支持超时的互斥体，即 mtx_timed 或 mtx_timed | mtx_recursive 互斥体。
这是否是草案的公正和疏忽？或者我错过了什么？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果互斥体不是递归的，但您尝试以递归方式锁定它，则行为未定义。然而，实现可以检测到这一点并返回 thrd_busy 。 （或者，它可能永远阻塞，或者返回
thrd_error，或者thrd_success，或者格式化你的硬盘......）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 returnthrd_error, orthrd_success, or format your hard disk.....)