TVarを使用してWebアプリケーションに状態を保存することを検討しています(再起動時に再作成できます)。ただし、TVar の競合の側面が気になります。実行時間の短いトランザクションが頻繁に発生すると、継続的にトランザクションが中断されるため、長時間のトランザクションが不足する可能性があるようです。また、実行時間の長いトランザクションが再起動し続けると、CPU の負荷が増加し、これらのトランザクションの長さがさらに長くなる傾向があります。最終的に、これによりサーバーが完全に応答しなくなる可能性があると思います。
これを考慮して、私はこれらの質問があります：
(1) TVar (または別のデータ型) は、同時試行/再試行ではなく、ロックを使用できますか。
(2) TVar (または別のデータ型) は、いくつかの異なる競合メカニズム、つまり「トランザクションを別のトランザクションを実行する前に 1 秒間実行させる」、または少なくともトランザクションが最終的に完了することを保証する (つまり、リソース不足を防ぐ競合アルゴリズム) を持つことができますか?実行時間の長いトランザクション)。
STM システム自体のランタイム コードを変更しない限り、飢餓の自由を保証する方法はないと思います。私の意見では、ロックを導入してTVars敗北間の競合を回避することは、そもそも STM を使用する目的です。STM を使用することの全体的なポイントは、並行プログラミングに対する古典的なエラーが発生しやすいロックベースのアプローチを取り除くことだからです。
確かに、飢餓は重大なパフォーマンスの低下を引き起こす可能性がありますが、そのような大規模なトランザクションが実際に必要であるという仮定の下でのみ. 私が念頭に置いている設計原則の 1 つはTVars、低い粒度レベルで使用することです。たとえば、エントリが更新されるたびに競合が発生する可能性がある全体Data.Mapをに入れる代わりにTVar、スキップリスト [1] のような、より STM に適したデータ構造を使用できます。
これは、データを更新する安価なトランザクションが多数あり、データを読み取る高価なトランザクションがいくつかある場合にのみ問題になります。おそらく、ライブで更新されたデータセットの分析。
これについて実際に懸念している場合は、フラグTVarの使用を検討してください。これをfalseに設定し、すべての安価なトランザクションの開始時にfalseであることを確認します。それ以外の場合は、呼び出しretryます。次に、長時間実行されるトランザクションを開始する前にtrueに設定し、終了時にfalseに設定します。または、の背後にある状態を単純に保護することもできますTMVar。長時間実行される計算は、tmvarをアトミックに取得し、それがどのように感じられるかを実行してから、それを返します。他のトランザクションは、完全に単一の実際のSTMトランザクション内で行われます。
また、長時間実行されるSTMトランザクションは、一種のトリッキーな獣であることを忘れないでください。怠惰のため、高価な値を安価に変数に入れることができます。また、多数の変数からデータの「スナップショット」を非常にすばやく読み取ることもできます。本当に長時間実行されるトランザクションを作成するには、多数の変数から読み取る必要があります。次に、読み取った内容に基づいて、新しい値を書き込む（または値を読み取る）変数とその計算自体を計算します。高価でなければなりません。そもそもそのシナリオにさえいない可能性があります。
これは、ピーターの回答に対するクリントンのコメントの1つに対するコメントとして書かれました。でも長くなりました。
A と B の 2 つの銀行口座があるとします。それぞれが独自のロックで保護されています。ここで、最初に A から B に送金し、2 番目に B から A に送金する 2 つのトランザクションがあります。それぞれが最初にソース アカウントのロックを取得し、次に宛先アカウントのロックを取得し、お金を転送してロックを解除します。運が悪いと、2 つのトランザクションがデッドロックに陥り、これら 2 つのアカウントで何も行われなくなります。STMでそれを行うと、それらは互いに実行されます。最初の種類が無限にある場合、それらは 2 番目のトランザクションを枯渇させる可能性があります。しかし、あなたはまだ多くのことを成し遂げています。ロックしている間は何も起こりません。
STM は、TVar とのデータ競合がないことを保証します! 何もありません。ロックを使用すると、コードを注意深く調べた後にその結論に達することができます。また、追加するすべての行が、結論を完全に無効にする可能性があります。