ソフトウェア トランザクション メモリを実際に使用した経験はありますか?[閉まっている]
https://stackoverflow.com/questions/209751
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
最近、STM (ソフトウェア トランザクション メモリ) フレームワークや言語拡張に対する関心が高まっているようです。 クロージュア 特に、を使用する優れた実装があります。 MVCC (マルチバージョン同時実行制御) ローリングコミットログではなく。GHC Haskellには、 非常にエレガントな STM モナド これにより、トランザクションの合成も可能になります。最後に、私自身の自戒を込めて、私は最近、 Scala 用 STM フレームワーク これにより、参照制限が静的に強制されます。
どれも興味深い実験ですが、その領域（実験）だけに限定されているようです。そこで私の質問は次のとおりです。現実世界で STM を見たり使ったりしたことがある方はいますか?もしそうなら、なぜですか？それはどのようなメリットをもたらしましたか？パフォーマンスについてはどうですか？(この点に関しては、多くの矛盾した情報があるようです) STM を再度使用しますか、それともアクターのような他の同時実行抽象化を使用したいですか?
解決
私はHaskellのBitTorrentクライアント（conjureという名前）の趣味開発に参加しました。 STMをかなり頻繁に使用して、異なるスレッドを調整します（ピアごとに1 +ストレージ管理用に1 +全体管理用に1）。
利点：ロックが少なく、読み取り可能なコード。
少なくともSTMの使用によるものではなく、速度は問題ではありませんでした。
これが役立つことを願って
他のヒント
記事「ソフトウェアトランザクショナルメモリ：なぜそれが研究玩具にすぎないのですか？」 Haskellの実装を見落としており、これは非常に大きな省略です。 STMの問題は、記事が指摘しているように、コンパイラーが安全であると証明できない限り（パフォーマンスを低下させる）すべての変数アクセスをトランザクション対応にするか、プログラマーにトランザクション変数を指定させる（単純さを低下させる）かを選択する必要があることですおよび信頼性）。ただし、Haskellの実装では、Haskellの純度を使用して、ほとんどの変数でトランザクションを使用する必要性を回避します。一方、型システムは、トランザクションミューテーション操作の効果的な強制とともにシンプルなモデルを提供します。したがって、Haskellプログラムは、スレッド間で真に共有される変数にSTMを使用しながら、非トランザクションメモリの使用を安全に保つことができます。
ガロア（Haskell内）の同時実行性の高いアプリには、かなり日常的に使用しています。動作し、Haskellの世界で広く使用されており、デッドロックしません（もちろん、あまりにも多くの競合が発生する可能性があります）。デザインが正しい場合は、MVarを使用するように書き直すこともあります（高速であるため）。
使用するだけです。それは大したことありません。私の知る限り、HaskellのSTMは「解決」されています。これ以上の作業はありません。使用します。
私たちは、 ファクトティスリサーチGmbH, 、実稼働環境では GHC で Haskell STM を使用しています。私たちのサーバーは、新規および変更された「オブジェクト」に関するメッセージのストリームを臨床「データ サーバー」から受信し、このイベント ストリームをオンザフライで変換し (新しいオブジェクトの生成、オブジェクトの変更、集約などによって)、これらの新しいオブジェクトのうちどれが新しいかを計算します。オブジェクトは接続された iPad と同期する必要があります。また、iPad からフォーム入力を受け取り、処理されて「メイン ストリーム」と結合され、他の iPad とも同期されます。すべてのチャネルとスレッド間で共有する必要がある変更可能なデータ構造に STM を使用しています。Haskell ではスレッドが非常に軽量であるため、パフォーマンスに影響を与えることなくスレッドを多数使用できます (現時点では iPad 接続ごとに 5 つ)。大規模なアプリケーションを構築するのは常に課題であり、学ぶべき教訓はたくさんありましたが、STM では問題が発生したことはありませんでした。それはいつもあなたの素朴な期待どおりに機能しました。本格的なパフォーマンス調整を行う必要がありましたが、STM はまったく問題になりませんでした。(時間の 80% は、短期間の割り当てと全体的なメモリ使用量を削減しようとしていました。)
STM は、Haskell と GHC ランタイムが真に輝く分野の 1 つです。これは単なる実験ではなく、おもちゃのプログラムだけのためのものでもありません。
私たちは Scala で臨床システムの別のコンポーネントを構築しており、これまでアクターを使用してきましたが、STM が本当に不足しています。実稼働環境で Scala STM 実装の 1 つを使用するのがどのようなものかについて経験のある方がいらっしゃいましたら、ぜひご意見を伺いたいと思います。:-)
システム（インメモリデータベースとランタイム）全体を実装しましたCでの独自のSTM実装の実装。これに先立ち、並行性に対処するためのログおよびロックベースのメカニズムがありましたが、これは維持するのが面倒でした。すべての操作を同じ方法で処理できるため、STMには非常に満足しています。ほとんどすべてのロックを削除できます。現在、あらゆるサイズのあらゆるものにSTMを使用しており、メモリマネージャーを実装しています。
パフォーマンスは良好ですが、速度を上げるために、共同でカスタムオペレーティングシステムを開発しましたETHチューリッヒと。システムはネイティブにトランザクションメモリをサポートしています。
しかし、STMによって引き起こされるいくつかの課題もあります。特に、不必要なトランザクションの競合を引き起こす大規模なトランザクションとホットスポットの場合。たとえば、2つのトランザクションがアイテムをリンクリストに入れると、ロックのないデータ構造を使用して回避できた不必要な競合が発生します。
