用undion_lock_t确切地锁定了什么
当我检查 andy_lock_t ， 它说andy_lock_t假定调用线程已经拥有穆特克斯的所有权。
那么，假设单词的含义是什么？如果我用同一互斥士尔（Alosex）声称锁（undion_lock_t）时，其他线程已经持有互斥X？
When I checked adopt_lock_t,
it says adopt_lock_t assume the calling thread already has ownership of the mutex.
So what's the meaning of the word assume? What if other thread already holding the mutex when I claim the lock(adopt_lock_t) with the same mutex?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果假设是错误的，则程序的行为不会受到C ++标准的约束。
所以不要弄错。
会发生什么？这超出了标准的决定。任何事物。合规的C ++编译器可以检查该条件，如果为此，则将您的网络浏览历史记录转移到父母。或者它可能崩溃。或僵局。否则您的硬盘驱动器可以格式化。
从QOI的角度来看，最有可能发生的是崩溃，或者您的并发代码是胡说八道（可能是锁定计数器上的底流）。 C ++标准状态表明，实施者对那里的任何合理行为概不负责，并且编译器可以根据已经持有锁定的假设自由优化。
最有可能的实现是构造函数不会锁定静音，而是在破坏者中解锁。当您在没有锁定的线程中解锁MUTEX时，会发生什么，无论是否锁定在另一个线程中，都将取决于实现。
If the assumption is wrong, the program's behavior is not constrained by the C++ standard.
So don't get it wrong.
What happens? That is outside of what the standard dictates. Anything. A compliant C++ compiler could check for that condition and, if true, transfer your web browsing history to your parents. Or it could crash. Or deadlock. Or your hard drive could be formatted.
As a matter of QoI, what would most likely happen is a crash, or your concurrency code being nonsense (an underflow on a lock counter maybe). The C++ standard states that implementors are not responsible for any kind of reasonable behavior there, and compilers are free to optimize based on the assumption the lock is already held.
The most likely implementation is that the constructor doesn't lock the mutex, but does unlock in the destructor. What happens when you unlock a mutex in a thread that doesn't have it locked, be it locked in another thread or not, is going to be implementation dependent.