問題タブ [stm]

STM トランザクションが失敗して再試行した場合、呼び出しwriteTChanが再実行されて 2 つの書き込みが発生するのでしょうか? それともトランザクションがコミットされた場合に STM が実際に書き込みを実行するだけでしょうか? つまり、寝ている床屋の問題に対するこの解決策は有効でしょうか? それとも、トランザクションenterShopが最初に失敗した場合、顧客は 2 つのヘアカットを受けるのでしょうか?

更新hairRequestChanとにかく、上記がトランザクションの一部である必要がない という事実の後まで、私は気づきませんでした。レギュラーを使用して、 のブロックの後のステートメントChanで実行できます。しかし、その改善を行うと、質問をする理由全体が破壊されるため、ここではそのままにしておきます。writeChanifatomicallyenterShop

STM (Software Transactional Memory) 関連のことは何も書いておらず、Web 上の情報を読んだだけです。したがって、これは単なる架空の例です

最大許容アイテムを含む FIFO バッファがあるとします。そのため、最大項目数に達するまで配列を埋め、それ以上項目がなくなったらシフトします。従来のアプローチでは、実際のシフトと追加だけでなく、最大値に達したかどうかをチェックする条件付き読み取りもロックします。そうしないと、2 つのスレッドがシミュレートして、残された唯一のアイテムがそれらに向けられたものであると判断できます。したがって、書き込みの競合とは直接関係のない一種の論理ロックがここにあります。

STM を使用すると、2 つのスレッドがアイテムが残っていると判断し、最後のアイテムを埋めようとすることができると思います。ただし、別のスレッドが同じメモリを変更したことを検出した後、1 つのスレッド (または両方) でロールバックが発生するため、正確性は維持されます。楽観的なシナリオでは、スレッドの 1 つが最終的に要素数を増やし、別のスレッドが最終的に別の分岐に移動する (FIFO シフト) と述べています。しかし、両方が最後のアイテムが残っていることに気づき、それを埋めようとすると、ここで無限ループの可能性も見えます。

では、STM 関連のソフトウェアを作成するときに「論理」ロックを追加する必要はありますか?

次の構造を持つ非常に単純なハッシュテーブルを考えてみましょう。

put、、 などの基本的な操作がgetありremoveます。を使用して並行してテストするためのいくつかのテストを作成しましたpcalls。最初に 1 つの " " で実行するテストを開発しthread(つまり、1 つの関数を使用して を呼び出すだけpcalls)、成功したため、問題はそこにはなく、removeスレッドセーフでない関数にあると想定する必要があります。

削除は次のように実装されます。

奇妙なことに、たった 1 つの要素のバケットが削除されないことさえあります。ベクトルの要素のみが参照であり、ベクトル全体ではないため、これは奇妙です。 質問: このコードがスレッドセーフでないのはなぜですか?

注:多くの人がこのアプリケーションの設計についてコメントしようとすることは承知していますが、これは私が興味を持っている種類の回答ではありません。純粋な機能コードを記述するよりも、clojure の STM を理解したいのです。

私は STM を使用して作業を行っており、特にTBQueueデータ構造を使用して大きな成功を収めています。TVar私がそれを使用してきた便利な機能には、基本的に次のように、 a の前提条件に基づいて読み取ることが含まれます。

このブロックを実行する前にqueueが空でshouldReadVar含まれていると仮定すると、結果として が呼び出され、最初に何が起こっても、要素を含むか含むときにブロックが再実行されます。TruereadTBQueueretryshouldReadVarFalsequeue

この記事(この質問を理解したい場合は読んでください)で説明されている構造と同様の同期チャネル データ構造が必要ですが、前の例のように前提条件で読み取り可能である必要があります。おそらく他のものと一緒に構成することもできます。

操作が定義されたこのデータ構造SyncChanを呼び出しましょう。writeSyncChanreadSyncChan

そして、考えられるユースケースは次のとおりです: この (疑似) コード (STM/IO の概念が混在しているため、機能しません):

writeSyncChan呼び出しで現在ブロックしているスレッドが他にないと仮定すると、 をshouldReadChan含むか、別のスレッドが をブロックするまで、Trueブロックを " " にしたい。言い換えれば、あるスレッドがオンになり、別のスレッドがブロックに到達したとき、またはその逆の場合、チャネルに沿って値を転送したいのです。それ以外の場合はすべて、読み取りまたは書き込みをキャンセルできるように、両側が の状態にあり、 の変化に反応する必要があります。retryshouldReadChanFalsewriteSyncChanretrywriteSyncChanreadSyncChanretryshouldReadVar

T上記のリンク先の記事で説明されている 2 つの ( )を使用した単純なアプローチMVarはもちろん不可能です。データ構造は同期的であるため、2 つのatomicallyブロック内で使用することはできません。これは、1つのブロックを変更して、別のブロックがアトミック コンテキストで変更されるTMVarのを待つことができないためです。TMVar

代わりに、トランザクションの特定の部分を「コミット」し、特定の変数が変更されたときにのみロールバックでき、他の変数は変更できない、一種の部分的な原子性を探しています。上記の記事の最初の例のように「msg」変数と「ack」変数がある場合、「msg」変数に書き込み、値が「ack」に到着するのを待つか、変更する他のトランザクション変数。他のトランザクション変数が変更された場合、アトミック ブロック全体が再試行され、「ack」値が到着した場合、トランザクションは以前の状態のまま続行されます。読み取り側についても、同様のことが起こるはずですが、もちろん "msg" から読み取り、"ack" に書き込みます。

GHC STM を使用してこれを行うことは可能ですか、または手動で MVar/ロールバック処理を行う必要がありますか?

次のコード (およびエラー) を検討してください。

誰かがどのよう(TChan (TChan Broadcast))になるのか説明できますか?

Clojure の STM トランザクションが再試行されているかどうか、およびその頻度をポーリングする方法はありますか?

Clojure では、並行性のために STM を使用します。

私の質問は、STM がデータの特定の時点の値を使用することです。これはあいまいさを導入していませんか?

アクセスされた値をどのように知ることができますか?

some-operation私は（例のように）一連の機能を持っていsendますsend-off。

このアプローチは、アプリを開発しているときにうまくいきました。しかし、コードベースにいくつかの変更を加えた後、エージェントはしばらくすると実行を停止します (「しばらく」は数秒で、数千の「再帰的」呼び出しです)。

それらの状態はドメイン内で有効であり、エージェント自体は有効ではなく、ブロックFAILEDでライブロックしていないことは確かです(競合を測定できます)。dosync

私の疑いは、何らかの理由で、JVM/OS が基になるエグゼキューター スレッドの実行を妨げていることです。しかし、この仮定が正しいかどうかを確認する方法がわかりません。

一般的に、送信エージェントが保留中の「送信」を実行できない理由として考えられるものは何ですか? 何を検査/測定できますか?

更新- デバッグ用に次の変更を行うと...

...エージェントはまだスタックしており、印刷さえしません:failed。

Clojure がソフトウェア トランザクショナル メモリを実装しており、Microsoft が C# の作業を完了しておらず、ここで説明されている STM の実装を非現実的なものにするいくつかの問題に気付いたのに、それに問題が見られないという可能性はどのようにあるのか疑問に思っています: http: //www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx

何かアイデアはありますか？

免責事項: これはMVar ()、 を単純なミューテックスとして使用して簡単に実行できます。それがSTMでできるかどうか、私は好奇心だけです。

私はアトミックに次のことをしたい：

• いくつかの変数を読み取ります。

• 今読んだ内容に基づいて、実行する I/O を決定します。

• I/O を実行します。

• 結果を変数に記録します。

具体的に言うと、読み取った入力のバイト数を追跡​​し、特定のバイト数が消費された後に EOF に達したと仮定します。(OK、2 つのスレッドが同じファイルから同時に読み取れるようにすることは、おそらく最初に行うべきではないことですが、これについては私と一緒に行ってください...)

明らかに、これは単一の STM トランザクションではありません。真ん中にI/Oがあります。明らかに、それを 2 つの接続されていないトランザクションとして持つことも間違っています。(2 つのスレッドが 1 バイトのクォータが残っていることを認識し、両方がそのバイトを読み取ることを決定する可能性があります。)

この問題の良い解決策はありますか? それとも、STM は単にこのタスクに不適切なツールなのでしょうか?