InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
Recently, I have been playing around with reader-writer (RW) locks. I have never encountered RW locks in practice, but I have read that they could be inefficient in practice, and often results in more harm than good. Recall that traditional mutex ensures that only one thread may enter a critical region. But if the critical region is being written infrequently, it is possible to exploit this concur
Boostに以前からread-writeロックは実装されていたようですがバグがあったとかで最近の物ではupgrade_lock, upgrade_to_unique_lockにさし変わっています。 ただのロックと比べてパフォーマンスが出やすい上に素性の良い設計だと思うので紹介してみようと思います。 read lock read-lockをする場合はshared_mutexを引数にshared_lockをかけてやればいいです。 #include <boost/thread.hpp> using namespace boost; shared_mutex mutex; void reader(){ shared_lock<shared_mutex> read_lock(mutex); // ここでロック! // クリティカルセクション } スコープを外れると同時にshared_lockのデスト
http://cpplover.blogspot.com/2011/07/mutex.html C++ のソースコード中に「途中のreturnや例外に気をつけること」などといったコメントはあってはならないため,補足. // 排他的にアクセスするリソース class exclusive_resource { public : std::vector<int> v ; private : std::mutex m ; public : void lock() { m.lock() ; } void try_lock() { m.try_lock() ; } void unlock() { m.unlock() ; } } ; exclusive_resource res1, res2 ; void thread1() {// res1のみを操作 std::lock_guard< exclusi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く