通过try_lock *,我的意思是try_lock(),try_lock_for()和try_lock_until().根据
cppreference,所有这三种方法可能都是虚假的.以下是对try_lock_for()的描述引用
As with try_lock(),this function is allowed to fail spuriously and
return false even if the mutex was not locked by any other thread at
some point during timeout_duration.
我知道虚假的唤醒可能会发生在std :: condition_variable和它背后的理由.但是,互斥体的情况如何？
解决方法
根据：
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3209.htm
On the other hand,there are strong reasons to require that programs be written to tolerate spurious try_lock() failures:
- As pointed out in Boehm,Adve,“Foundations of the C++ Concurrency Memory Model”,PLDI 08,enforcing sequential consistency for data-race-free programs without spurious try_lock() failures requires significantly stronger memory ordering for lock() operations on try_lock()-compatible mutex types. On some architectures that significantly increases the cost of uncontended mutex acquisitions. This cost appears to greatly outweigh any benefit from prohibiting spurious try_lock() failures.
- It allows a user-written try_lock() to fail if,for example,the implementation fails to acquire a low-level lock used to protect the mutex data structure. Or it allows such an operation to be written directly in terms of compare_exchange_weak.
- It ensures that client code remains correct when,a debugging thread is introduced that occasionally acquires locks in order to be able to read consistent values from a data structure being checked or examined. Any code that obtains information from try_lock() failure would break with the introduction of another thread that purely locks and reads the data structure.
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
