升级的boost :: shared_lock独占锁 [英] Upgrading boost::shared_lock to exclusive lock

问题描述

可能有人请解释的boost :: upgrade_lock的正确用法。下面code导致死锁

Could someone please explain the correct usage for boost::upgrade_lock. The following code results in a deadlock

//Global
typedef boost::shared_mutex Mutex;
typedef boost::shared_lock<Mutex> ReadLock;
typedef boost::upgrade_lock<Mutex> UpgradeLock; 
typedef boost::upgrade_to_unique_lock<Mutex> WriteLock;
Mutex sharedMutex;


//Multi threaded reader and writer
{
    ReadLock read(sharedMutex);

    for (int ii = 0; ii < vec.size(); ++ii) {
        Element e = vec[ii];

        if (e.needsUpdating()) {
            UpgradeLock upgrade(sharedMutex);

            WriteLock write(upgrade)

            //Do stuff
        }
    }
}

如果我在升级前解除与read.unlock读锁（）不死锁。但似乎，这不应该是必要的？

It doesn't deadlock if i unlock the read lock with read.unlock() before upgrading. But it seems that this shouldn't be necessary?

推荐答案

在的boost :: shared_mutex 类（它实现了UpgradeLockable概念），单个线程不应该尝试获取双方共享和升级（或唯一的）锁。在任何时候，UpgradeLockable可以有N个共享的锁（通过 lock_shared ），和1个可升级锁定（通过 lock_upgrade ）。可升级的锁可以要求它成为一个独特的锁，这阻塞，直到它可以成为独特的持有人，要求所有共享锁被释放。这是不可能的，从共享锁转换为唯一的锁，或一个共享锁到可升级锁没有首先释放共享锁。

In the boost::shared_mutex class (which implements the UpgradeLockable concept), a single thread should not attempt to acquire both a shared and an upgradeable (or unique) lock. At any time, the UpgradeLockable can have N shared locks held (via lock_shared), and 1 upgradeable lock (via lock_upgrade). The upgradeable lock can request that it become a unique lock, which blocks until it can become the exclusive holder, which requires all shared locks be released. It is impossible to convert from a shared lock to a unique lock, or a shared lock to an upgradeable lock without releasing the shared lock first.

请注意，可升级的锁是不是唯一的（其他共享锁可持有）只是它具有特殊的权限，以增加它的强度。不幸的是，多升级的线程不同时允许

Note, the upgradeable lock is not exclusive (other shared locks can be held) just that it has special privileges to increase it's strength. Unfortunately, multiple upgradeable threads are not allowed at the same time.

在您的情况下，在同一个线程试图使用 lock_shared 和 lock_upgrade ，这将死锁。您可以如下改写它，它也不会僵局，但它仍然是争夺所有的读者单点，因为只有1将举行一次升级锁。在这种情况下，这取决于你等功能，一个shared_mutex的复杂性可能是不必要的。但是，如果其他功能仍获取共享锁，那么下面会像您期望的执行。

In your case, the same thread is attempting to use lock_shared and lock_upgrade, which will deadlock. You can rewrite it as below, and it won't deadlock, but it's still a single point of contention for all of the readers, since only 1 will hold the upgrade lock at a time. In which case, depending on your other functions, the complexity of a shared_mutex might not be necessary. However, if other functions are still acquiring shared locks, then the below will perform as you expect.

//Multi threaded reader and writer
{
    // Only 1 thread can pass this.  Other shared locks are also valid
    UpgradeLock read(sharedMutex); 

    for (int ii = 0; ii < vec.size(); ++ii) {
        Element e = vec[ii];

        if (e.needsUpdating()) {
            // Blocks here until all shareds are released
            WriteLock write(upgrade)

            //Do stuff
        }
    }
}

这篇关于升级的boost :: shared_lock独占锁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！