最近、STM (ソフトウェア トランザクショナル メモリ) フレームワークと言語拡張への関心が高まっているようです。 特にClojureは、ローリング コミット ログではなくMVCC (マルチバージョン同時実行制御)を使用する優れた実装を備えています。GHC Haskell には、トランザクション合成も可能にする非常にエレガントな STM モナドもあります。最後に、私自身の口癖を少しだけ説明するために、私は最近、参照制限を静的に適用する Scala 用の STM フレームワークを実装しました。
これらはどれも興味深い実験ですが、その領域だけに限定されているようです (実験)。私の質問は、現実の世界で STM を見たり使用したりしたことがある人はいますか? もしそうなら、なぜですか？それはどのような利益をもたらしましたか。パフォーマンスはどうですか？(この点については多くの矛盾する情報があるようです) STM を再び使用しますか、それともアクターのような他の並行処理の抽象化を使用したいと思いますか?
Haskell での BitTorrent クライアント (conjure という名前) の愛好家による開発に参加しました。STM をかなり頻繁に使用して、さまざまなスレッドを調整します (ピアごとに 1 つ + ストレージ管理用に 1 つ + 全体的な管理用に 1 つ)。
利点: ロックが少なく、コードが読みやすい。
少なくとも STM を使用しているため、速度は問題ではありませんでした。
お役に立てれば
Galois（Haskell）の同時実行性の高いアプリにかなり日常的に使用しています。それは機能し、Haskellの世界で広く使用されており、デッドロックは発生しません（もちろん、あまりにも多くの競合が発生する可能性があります）。設計が適切であれば、MVarを使用するように書き直すことがあります。これは、MVarの方が高速であるためです。
使用するだけです。それは大したことありません。私に関する限り、HaskellのSTMは「解決」されています。これ以上行う作業はありません。だから私たちはそれを使います。
記事「Software Transactional Memory: Why is it Only a Research Toy?」(Călin Caşcaval 他、Communications of the ACM、2008 年 11 月)、Haskellの実装を見ていません。これは本当に大きな省略です。この記事で指摘されているように、STM の問題は、コンパイラーがそれらを安全であると証明できない限り、すべての変数アクセスをトランザクション対応にするか (パフォーマンスを損なう)、どれをトランザクション対応にするかをプログラマーに指示させるか (単純さを損なう) のいずれかを実装が選択しなければならないことです。と信頼性）。ただし、Haskell の実装では Haskell の純粋性を利用して、ほとんどの変数の使用をトランザクション化する必要がないようにしています。一方、型システムは単純なモデルと、トランザクションによるミューテーション操作の効果的な実施を提供します。したがって、Haskell プログラムは、非トランザクション メモリの使用が安全に保たれることを保証しながら、スレッド間で真に共有される変数に STM を使用できます。
私たち、factis research GmbHは、Haskell STM と GHC を本番環境で使用しています。私たちのサーバーは、臨床の「データサーバー」から新規および変更された「オブジェクト」に関するメッセージのストリームを受信し、このイベントストリームをオンザフライで変換し (新しいオブジェクトの生成、オブジェクトの変更、物事の集約などによって)、これらの新しいものを計算します。オブジェクトは、接続された iPad に同期する必要があります。また、処理され、「メイン ストリーム」とマージされ、他の iPad と同期される iPad からのフォーム入力も受け取ります。スレッド間で共有する必要があるすべてのチャネルと変更可能なデータ構造に STM を使用しています。Haskell ではスレッドは非常に軽量であるため、パフォーマンスに影響を与えずに多数のスレッドを使用できます (現時点では、iPad 接続ごとに 5 つ)。大規模なアプリケーションの構築は常に挑戦であり、学ぶべき多くの教訓がありましたが、STM で問題が発生したことはありません。あなたが素朴に期待するように、それは常にうまくいきました。本格的なパフォーマンス チューニングを行う必要がありましたが、STM が問題になることはありませんでした。(80% の時間は、短期間の割り当てと全体的なメモリ使用量を削減しようとしていました。)
STM は、Haskell と GHC ランタイムが真価を発揮する分野の 1 つです。これは単なる実験ではなく、おもちゃのプログラムだけのものでもありません。
Scala で臨床システムの別のコンポーネントを構築しており、これまで Actors を使用してきましたが、STM が本当に不足しています。本番環境で Scala STM 実装の 1 つを使用するのがどのようなものか経験のある方がいらっしゃいましたら、ぜひお聞かせください。:-)
C での独自の STM 実装の上に、システム全体(メモリ内データベースとランタイム) を実装しました。これに先立って、同時実行を処理するためのログとロック ベースのメカニズムがいくつかありましたが、これを維持するのは面倒でした。すべての操作を同じ方法で処理できるため、STM には非常に満足しています。ほとんどすべてのロックを取り外すことができました。私たちは現在、あらゆるサイズのほぼすべてのものに STM を使用しており、その上にメモリ マネージャーを実装しています。
パフォーマンスは問題ありませんが、速度を上げるために、ETH Zurich と共同でカスタムオペレーティング システムを開発しました。システムは、トランザクション メモリをネイティブにサポートします。
しかし、STM によって引き起こされる課題もいくつかあります。特に、不必要なトランザクションの競合を引き起こす大規模なトランザクションやホットスポットでは。たとえば、2 つのトランザクションがリンクされたリストにアイテムを配置した場合、ロックのないデータ構造を使用して回避できたはずの不必要な競合が発生します。