通过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
returnfalseeven if the mutex was not locked by any other thread at
some point duringtimeout_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.
