問題タブ [transactional-memory]

gcc docs: x86-transactional-memory-intrinsics.htmlにより、トランザクションが失敗/中止された場合、_xbegin()は中止ステータスを返す必要があります。ただし、時々0が返されることがあります。そしてその頻度は非常に高いです。**_xbegin()** が 0 を返すのはどのような状況ですか?

マニュアルを確認したところ、多くの状況でこの結果が生じる可能性があることがわかりました。たとえば、CPUID、SYSTEMCALL、CFLUSH.etcです。ただし、私のコードがそれらのいずれもトリガーしたとは思いません。

これが私のコードです：小さな銀行をシミュレートし、別の口座に1ドルをランダムに送金します。

サプリメント:

1. すべてのアカウントは 64 ビットに揃えられています。bank->accounts[0], bank->accounts 1のアドレスを印刷しました。0xf41080，0xf410c0。</li>
2. -O0 を使用するasm volatile("":::"memory");ため、命令の並べ替えの問題はありません。

3. アボート率は時間とともに増加します。これが結果です

   /li>

4. n_threads が 1 であっても、結果は同じです。

5. 次のようにフォールバック後に粗いロックを追加すると、結果は正しいようです。

   /li>

私のクラスのようにすべての関数を宣言するだけで十分なので、 Experimental Transactional Memory TS からtransaction_safeのトランザクションでスレッドセーフとして使用できますか?atomic_noexcept, atomic_cancel, atomic_commit

知られているように、Experimental C++ 標準ライブラリには Transactional Memory TS (ISO/IEC TS 19841:2015) があります。簡単な例はこちら: http://en.cppreference.com/w/cpp/language/transactional_memory

また、トランザクション メモリの C++ 拡張機能の技術仕様もあります: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.pdf

34ページ：

つまり、トランザクショナル メモリが C++ 標準にコミットする場合、単純にこのようなことを行うことができ、それはスレッド セーフになりますか?

残念ながら、GCC 6.1atomic_cancel {}のキーを使用しても例を再現できません: https://godbolt.org/g/UcV4wI-fgnu-tm

そして、一部のクラスのようにすべての関数を宣言するだけで十分なtransaction_safeので、スレッドセーフとして使用できます-スコープ内で呼び出す場合: atomic_cancel { obj.func(); }?

知られているように、Experimental C++ にはトランザクション メモリ TS (ISO/IEC TS 19841:2015) があります。

コンテナー専用としてoperator[]宣言: , , , , _transaction_safestd::vectorstd::unordered_mapstd::unordered_multimapstd::unordered_setstd::unordered_multisetstd::deque

23.4 連想コンテナ [associative]

23.4.4 クラス テンプレート マップ [マップ]

23.4.4.1 クラス テンプレート マップの概要 [map.overview]

23.4.4.1 [map.overview] で、begin メンバー関数と end メンバー関数のすべてのバリアントの宣言と、size、max_size、および empty の宣言に「transaction_safe」を追加します。

しかし、andがoperator[]宣言されtransaction_safeていないのはなぜですか(ただし、for /はあります)。std::mapstd::setunordered_mapunordered_set

beginまた、 andのendメンバー関数のすべてのバリアントの宣言に「transaction_safe」を追加するのはなぜstd::mapですかstd::set?

イテレータbeginとは、またはendには非常に必要ですが、連想配列には必要ありません。連想配列では、検索または検索と変更の機能が必要でした: 、、、および。それらがなければ意味がありません。std::arraystd::vectorstd::listfindatinserteraseoperator[]

注文された std::map と注文された std::set が transaction_safe に招待されないのはなぜですか?

同時に使用できるかどうかに関係なく、新しいクラスを作成するとします。明らかに、同時に呼び出される可能性があるすべてのものをロックしたくはありません。これに対処する 1 つの方法は、ロックを指定するミックスインによるパラメーター化です。

Lockingマルチスレッドの場合は実際にロックするクラスでインスタンス化し、他の場合はノーオペレーションを行うクラスでインスタンス化します (うまくいけば、コンパイラは呼び出しを最適化します)。

ここで、ロックの代わりにソフトウェア トランザクション メモリを使用してこれを行いたいとします。N3919 (またはgcc 前駆体)を見ると、考え方が異なります。などの呼び出しはありません。

代わりに、次のような関数指定子があります

およびブロック指定子のような

後者が前者を呼び出すという厳格なルールがあり、そのように見えるものはミックスインで使用できません。

これを行うにはどうすればよいですか (プリプロセッサを使用せずに)。また、STM の主な利点の 1 つはコンポーザビリティbarですが、トランザクション可能であることをインスタンス化に反映させる方法はないようです。

C++17 のトランザクショナル メモリの提案の現在のステータスは何ですか。それは、標準 C++ の将来のバージョンに含まれることを目的として、標準に含まれる予定ですか? それとも、標準化のステータスがまだ未定で、実験的な概念実証機能にすぎませんか?

標準化委員会の文書のいくつかは、ここで矛盾したコミュニケーションを与えているように見えるので、私は尋ねています。一方では P0265R0 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0265r0.pdf ) が、トランザクション メモリが標準化される予定はないと言っています。手 - C++ 17 機能リストに記載されているトランザクショナル メモリを使用した Stroustrup ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4492.pdf ) による N4492 論文があります。

以下のコンパイルの失敗は libstdc++ の欠陥によるものですか? それとも、この動作はトランザクション メモリ TS ( n4514 ) に準拠していますか?

アクターベースおよびロックベースの同期と比較した場合のトランザクション メモリはどれくらいですか?

私が理解している限り、これは同時実行制御の別のメカニズムです。それとも、アクター、イベント、ロックなどとはまったく別のものですか？