的std :: atomic_flag和std :: lock_guard

由於std::lock_guard不std::atomic_flag工作，我已經實現了我自己的版本：的std :: atomic_flag和std :: lock_guard

class atomic_guard { 
public: 
    inline atomic_guard(std::atomic_flag& lock) : lock(lock) { 
     while (this->lock.test_and_set()) { 
      /* spin */ 
     }; 
    }; 

    inline ~atomic_guard() { 
     this->lock.clear(); 
    }; 

private: 
    std::atomic_flag& lock; 
};

這似乎很好地工作。問題是：這是實施RAI的正確方法嗎？還有一個內置的後衛嗎？如果不是，爲什麼？專業std::lock_guard<std::atomic_flag>看起來很自然。

來源

2017-04-21 freakish

如果使用atomic_guard作爲獨立的互斥量外觀是正確的，但稍有不同。

使用std::atomic_flag直接使用std::lock_guard是不可能的，因爲std::lock_guard模板管理互斥鎖，而std::atomic_flag是（低級別）原子布爾類型。

可以與std::lock_guard使用mutex的實現必須提供的成員函數lock和unlock，可以這樣實現：

class my_mutex { 
    std::atomic_flag flag{ATOMIC_FLAG_INIT}; 

public: 
    void lock() 
    { 
     while (flag.test_and_set()); 
    } 

    void unlock() 
    { 
     flag.clear(); 
    } 
};

注意，這是一個非常基本的和低效的互斥執行，但它是與std::lock_guard兼容：

my_mutex mtx; 

std::lock_guard<my_mutex> lck{mtx};

來源

2017-04-21 16:05:53 LWimsey

「低效率」是什麼意思？標準互斥是不是更有效率的atomic_flag？至少在某些情況下，例如當鎖定時間應該是短暫的。 – freakish

@freakish如果一個線程正在等待使用'my_mutex'來獲取鎖，那麼它正在浪費很多CPU時間，因爲它在繁忙的while循環中 – LWimsey

我不會稱之爲「浪費」。你獲得執行時間，所以它是一個交易。看起來atomic_flag甚至可以比標準互斥量快50倍。所以如果你鎖定很短的時間，那麼「浪費」這些CPU週期可能是值得的。這裏是基準測試：https://www.arangodb.com/2015/02/comparing-atomic-mutex-rwlocks/當然，我會在我的場景中進行適當的測試，但我預計至少會有2x加速。 – freakish

的std :: atomic_flag和std :: lock_guard

回答

相關問題