私<thread> <atomic> <mutex>はコードでetcを多用していますが、これにはいくつかのロックフリーアルゴリズムが含まれています。私は（最終的には）Linux環境をターゲットにしています。私はVisualStudio2011 Betaを使用して開発してきましたが、他のC ++ 11機能にはひどく欠けていますが、並行機能を実装する唯一のツールチェーンのようです。
ここでc++11のサポートを参照してください。
他の人がc++11の同時機能を含むライブラリを単に欠いている場合、私は簡単にちょうど:: threadを使用できますが、clangとgccの両方がc++11メモリモデルに「いいえ」と答えます。少なくともビジュアルc++はサポートしているようです。 。これがどのような影響を与えるかは正確にはわかりません。おそらく、他の誤ったものの中でも、明らかに副作用のないコードを最適化することです。
今のところ、最適化されたビルドを完全に避け、最適化を有効にせずにデバッグビルドのみをコンパイルする場合、ClangまたはGCCツールチェーンを使用するのは合理的ですか？
C++ メモリ モデルの作業は進行中であり、次の GCC リリースで完了する予定です。GCC 4.7 がリリースされたので、これが期待できるものです。
- サポートされているロックフリー命令の完全なアトミック実装。すべてのアトミック操作は新しい __atomic ビルトインで実装されており、ほとんどのターゲットは生成されるコードのメモリ モデル パラメータを反映しています。最適化によって共有メモリ操作がアトミック操作を超えて移動することはないため、さまざまな発生関係が尊重されます。
- (ハードウェアまたは OS サポートのいずれかを介して) ロックフリー命令が利用できない場合、アトミック操作は、ライブラリによって解決される関数呼び出しとして残されます。時間の制約と最終化されていない API のため、GCC 4.7 で提供される libatomic はありません。これは、 _atomic *で始まる満たされていない外部シンボルに遭遇することで簡単に判断できます。
- プログラムでライブラリの支援が必要な場合は、単一の C ファイル サンプル実装をコンパイルしてクライアント プログラムにリンクし、ロックされた実装を使用してこれらの外部関数呼び出しを解決することができます。libatomic のサンプルをダウンロード
- C++ テンプレートは、任意のサイズのオブジェクトを完全にサポートしますが、前述の libatomic.c ファイルは、一部のユーザー定義クラスを満たすために必要になる場合があります。クラスが、サポートされているロックフリーの整数型と同じサイズにマップされている場合、ロックフリーのルーチンも使用されます。
- ビットフィールドはメモリ モデルに準拠していません。つまり、読み取りまたは書き込み時のワード全体へのアクセスにより、ロードまたはストアのデータ競合が発生する可能性があります。
- いくつかの作業は行われていますが、最適化はコンプライアンスについて完全には監査されていません。一部の最適化では、以前には存在しなかった新しいデータ競合が発生する可能性があります。既知のケースの数は少なく、コンプライアンスのテストは簡単ではありません。最適化によって新しいデータ競合が発生するケースに遭遇した場合は、対処できるようにバグジラ ケースを開いてください。
LLVM でのサポートはさらに進んでいるようです: http://llvm.org/releases/3.0/docs/Atomics.html
ただし、これが実際に clang でどの程度使用されているかを判断するのは困難です。<atomic>基本的にいくつかのタイプで機能するようです。アトミック型が予期しないものであるという他の型のコンパイラ アサーションを取得しています。これにより、動作する型に少し自信が持てます。
私は 64 ビットの Linux と Windows で gcc-4.7 を使用して成功しました。std::threadなどは、gcc-4.6 でも Linux で完璧に動作します。
Windows では、gcc-4.7 (mingw64) にいくつかのマイナーな問題があり、std::condition_variableAFAIR のデストラクタでメモリ リークが発生します。