std :: condition変数を使用したスレッド安全性

Question

clangスレッドセーフティモデルの後に、以下のミューテックスクラス（うまくいけば）を実装しました。以下の（http://clang.llvm.org/docs/ThreadSafetyAnalysis.html）

class CAPABILITY("mutex") Mutex : public std::mutex 
{ 
    public: 
    void lock() ACQUIRE() 
    { 
     std::mutex::lock(); 
    } 

    void unlock() RELEASE() 
    { 
     std::mutex::unlock(); 
    } 
}; 

class SCOPED_CAPABILITY LockGuard : public std::unique_lock<std::mutex> 
{ 
    public: 
     LockGuard(Mutex& mu) ACQUIRE(mu) : std::unique_lock<std::mutex>(mu) 
     { 
     } 

     ~LockGuard() RELEASE() 
     { 
     } 
}; 

利用がされて： warning: reading variable 'count_' requires holding mutex 'mutex_' [-Wthread-safety-analysis]：

class Barrier 
{ 
    ... 

    Mutex mutex_; 
    std::condition_variable cv_ GUARDED_BY(mutex_); 
    std::size_t min_count_ GUARDED_BY(mutex_); 
    std::size_t count_ GUARDED_BY(mutex_); 

    bool Barrier::waitFor(const std::chrono::microseconds& duration) 
    { 
     LockGuard lock(mutex_); 
     if (count_ >= min_count_) 
     { 
      return true; 
     } 
     else 
     { 
      // WARNING IS IN THE LINE BELOW 
      return cv_.wait_for(lock, duration, [this]() { return count_ >= min_count_; }); 
     } 
    } 
}; 

は私が打ち鳴らす警告が表示されます。

コンパイラ（-Wthread-safetyのclang 3.8）の警告は正しいですか？はいの場合、違反はどのくらい正確に起こりますか？

Answer 1

このコードは非常に問題です。 unique_lockから継承していますが、正しく構築されていません。ロック/アンロックする独自のミューテックスがありますが、unique_lockが所有するものは初期化されずに残ります。条件変数wait_forは、親ロックでreleaseを呼び出し、ロックされていないミューテックスを解放します。

私は、カスタムクラスでのロックの再実装のこの演習に従事する理由はありません。標準ライブラリクラスはほとんどであり、は継承されないことを覚えておいてください。

Answer 2

ラムダ式が評価されるコンパイラには明確ではないため、ラムダにも注釈を付ける必要があります。

任意のエラーを得られない、正しいラインは、我々はいくつかのコンパイラと異なるstdlibsでコンパイルする必要があり

return cv_.wait_for(lock, duration, [this]() REQUIRES(mutex_) { return count_ >= min_count_; });