atomic compare_exchange_weak/strong関数 - yohhoyの日記
C++11標準ライブラリのatomic操作関数compare_exchange_weakとcompare_exchange_strongについてメモ。 両関数ともに変数のatomicなCAS(compare-and-swap)操作を提供する。weak版とstrong版との動作仕様は、weak版では “交換可能な場合でもCAS操作失敗する可能性がある(spurious failure)”*1 が、strong版では “交換可能な場合は常にCAS操作が成功する” という点のみ異なる。当初はweak版のみが定義されていたが、強いCAS操作命令をもつハードウェア性能を生かすために、N2748にてstrong版が追加された。 利用指針は下記の通り。大抵のケースでは ループ構造＋compare_exchange_weakでよい（はず）。 アルゴリズム上、CAS操作をループで括る必要があればcompar
volatile変数とマルチスレッドとの関係についての押し問答（後編） - yohhoyの日記
プログラミング言語C++のvolatile変数がスレッド間の同期機構として機能するか否かという論点について、有りそうな質問とその答えについての簡易メモの続きの続き。（自身の思考整理用） ある変数がスレッド間の同期機構として機能するためには、下記3つの性質が保証されることが要求される。volatile変数ではこれらのいずれも保証されないため、同期機構としては利用できない。 原子性(atomicity) → id:yohhoy:20121016 可視性(visibility) → id:yohhoy:20131009 順序性(ordering) 順序性の保証 注意：簡単のため、atomic変数への逐次一貫性(sequential consistency)アクセスのみを対象とする。これはC++11 atomicアクセス操作における既定動作である。 説明のためコード例示に番号[A]〜[D]を追加付
volatile変数とマルチスレッドとの関係についての押し問答（中編） - yohhoyの日記
プログラミング言語C++のvolatile変数がスレッド間の同期機構として機能するか否かという論点について、有りそうな質問とその答えについての簡易メモ（→id:yohhoy:20121016）の続き。（自身の思考整理用） ある変数がスレッド間の同期機構として機能するためには、下記3つの性質が保証されることが要求される。volatile変数ではこれらのいずれも保証されないため、同期機構としては利用できない。 原子性(atomicity) 可視性(visibility) 順序性(ordering) 原子性の保証 前回記事では、原子性(atomicity)の保証についてのみ説明している。 volatile変数ではダメだという反例を挙げよ volatile変数への読み書きは不可分(atomic)操作であるとは保証されない。仮にレジスタサイズ2byte長のマシンを想定した場合、同環境では4byteサ
volatile変数とマルチスレッドとの関係についての押し問答（前編） - yohhoyの日記
プログラミング言語C++のvolatile変数がスレッド間の同期機構として機能するか否かという論点について、有りそうな質問とその答えについての簡易メモ。（自身の思考整理用） 結論：このプログラムは可搬性が無く、未定義動作(undefined behavior)を引き起こす。C++11ではvolatile変数でなくatomic変数を用いるべき。C++03以前ではコンパイラ依存の仕組みを利用する。 volatile int running = 1; // 処理スレッド void another_thread() { while (running) { // ??? //... } } // 制御側スレッド void main_thread() { //... running = 0; // ??? } C++言語仕様ではどう定義される？(C++03以前) C++03以前のC++言語仕様ではそも
「pthreadサポート」の意味するところ - yohhoyの日記
ある処理系が “POSIXスレッド(pthread)標準をサポートする” とき、処理系（実行環境を含む）で担保すべき事項と、利用者（アプリケーションプログラマ）が守るべき制約についてメモ。 アプリケーションをプログラマの意図通り実行させるための、処理系／利用者間の責任分解点は「メモリ同期(memory synchronization)」により定義される。 利用者：複数スレッドからの少なくともどれか1つが書込操作となる変数アクセスの場合、“メモリ同期関数” を用いた排他制御により変数アクセスが同時に生じないよう保証すること。 全てが読込操作である変数アクセスの場合、複数スレッドからの変数アクセスを同時に行ってもよい。（そのようなコードを書いても、意図通り実行されることが保証されている。） 処理系：コンパイル時に最適化を行う場合でも、あるスレッド内での変数アクセス操作を “メモリ同期関数” 呼
なんちゃってScopeExit - yohhoyの日記
「nullptrを所有するshared_ptr」を使って何か面白いことが出来ないかと適当にひねり出した応用例。 C++11標準ライブラリだけで Boost.ScopeExit（スコープガード）のお手軽実装。 #include <memory> #define MY_SCOPE_EXIT(name_, ...) \ std::shared_ptr<void> name_(nullptr, [&](void*)__VA_ARGS__) 利用例： void process(int a, int b) { std::cout << "BEGIN" << std::endl; MY_SCOPE_EXIT(guard, { // 変数は(参照)キャプチャ済み std::cout << "EXIT" << func(a, b) << std::endl; /* カンマ(,)があっても大丈夫 */ });
条件変数とダンス(Two-Step Dance)を - yohhoyの日記
条件変数(condition variable)同期プリミティブに対する待機／通知で発生する現象と回避策のメモ。 条件変数とミューテックスを使ったコードにおいて次のような現象が生じる。 スレッドAが条件変数cvに対して通知を行う。 条件変数cvに対してブロックされていたスレッドBのブロックが解除される。ただし、ミューテックスmtxはスレッドAにロック保持されたままのため、再びスレッドBはミューテックスmtxに対してブロックされる*1。 スレッドAがミューテックスmtxのロックを解放する。 ミューテックスmtxに対してブロックされていたスレッドBがブロック解除され、同ミューテックスのロック獲得に成功する。 #include <pthread.h> int data = 0; // 待機条件: 非0になるまで待機 pthread_mutex_t mtx; pthread_cond_t cv;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
