問題タブ [stm]

こんにちは、tcp 経由でメッセージを送受信し、接続が切断された場合に自動再接続する関数を作成する必要があります。メッセージは STM チャネルから取得されます

私の問題は、接続が切断された場合、チャネルから読み取った「c」が失われることです。したがって、catch節では unGetTChan のようなものは必要ありませんが、このコードでは 'c' がキャッチされていません。そのようなことを行うための ''haskellic'' な方法を教えてもらえますか?

FUZxxlのメッセージの後に更新

FUZxxlのコメントの後、関数を次の形式に書き直しました

今ではうまくいきます。ありがとう

私は Scala と Akka を初めて使用し、問題を解決するために使用することを検討しています。計算エンジン (解を検索する) があるとします。各ノードの各CPUに独自のエンジンインスタンスを与えることで、CPU全体とノード全体の両方でその検索を並列化したいと思います。

エンジン入力は、少数のスカラー入力と非常に大きなハッシュ テーブルで構成されます。各エンジン インスタンスは、そのスカラー入力を使用してハッシュ テーブルに小さなローカル変更を加え、良さを計算してから、その変更を破棄します (他のエンジン インスタンスによってコミット/表示される必要はありません)。良さの値は、結果の中から選択するコーディネーターに返されます。

共有状態の手段としての STM TransactionalMap について読んでいました。これは理想的に思えますが、これを共有状態として使用する完全な例は実際には見当たりません。

質問:

• アクター/stm モデルはこの問題に適しているように見えますか?
• 共有状態を配布する具体的な例を教えてください。(メッセージとして Ref[TransactionalMap[,]] ですか?
• 異なるノード間ではなく、ノード内で共有状態を分散することに違いはありますか?

探究心が知りたい、

アラン

TVarは単純なコンテナですが、はとTMVar同じですMVar。つまり、ロックなどがありますが、モナド内にありますSTM。STMロックを不要にするのが目的なので、なぜそれが必要なのか疑問に思います。

[Handle]では、たとえば、によって作成されたスレッド間で使用するソケットハンドルのリストのようなタイプがある場合は、どちらを使用しforkIOますか？

私はScalaとAkkaを初めて使用するので、これが新しい質問である場合はご容赦ください。しかし、他のどこにも答えが見つかりません...

記録のために、私はScala2.9.0-1とAkka1.1.3を使用しており、SBT0.10.1セットアップも含めています。

このメッセージに続くコードは、Akkaでの実験として作成しました。これは、ユーザーデータベースと登録機能のおもちゃバージョンです。基本的な考え方は、UserServerアクターのActorPoolがあり、それぞれがSTMを使用してユーザーの電子メールアドレスをキーオフしたユーザーのマップと対話するMemoryUserDatabaseのインスタンスを持っているということです-非常に単純ですよね？

この問題は、ファイルをコンパイルし、2つの別々のコンソールで以下を実行することで再現できます。

コンソール＃1：

インポートtoy.service.user._; ServiceRunner.run

コンソール＃2：

インポートtoy.service.user._; ClientRunner.run

これはサーバーコンソールからの出力です（＃1）

このエラーは、Scala2.9.1.finalを使用すると少し興味深いものになります。

コードのこの有効な部分は次のとおりです。

コンパニオンオブジェクトを初期化できない理由がわかりません。最も奇妙な部分は、同じことを実行できることですが、サーバーコンソール（＃1）で最初にコンパニオンオブジェクトにアクセスする場合は、次のようになります。

MemoryUserDatabase

ServerRunnerを実行する前は、正常に初期化され、その後、他のすべてが正常に初期化されます。

誰かがこれがなぜであるか説明できますか？

ありがとう！イダン

PS。これは私の最初のScalaコードなので、あまり笑わないようにしてください...そして他の提案（文体、哲学、神学など）は大歓迎です。

私は最近、私のプロジェクトでいくつかの部分に STM を使い始めましたが、それをテストする方法を理解するのに苦労しています。

これらの関数には IO がなく、QuickCheck プロパティを記述してテストできることを望んでいましたが、「アトミックに」(STM a -> IO a) が STM モナドから何かを取得する唯一の方法のようです。

これは可能ですか、それとも代わりに HUnit でテストを作成する必要がありますか?

私はしばらくの間 S​​cala に手を出しており、遠くから Akka を研究してきましたが、ついに本格的に始めようとしています。FSM トレイトが私の契約を結びました。私が懸念しているのは、データが不適切に共有される方法を思いついた可能性があることと、Akka のベスト プラクティスに一致するようにイベント処理ループを誤って考えた可能性があることです。

私の問題では、着信タスク要求を、有限状態マシンでもある適切なアクターに一致させる中央コーディネーターがいます。私は当初、onTransition が状態名だけでなく状態データも提供すると想定していました。

従来のデータのカプセル化が、そのデータをリスナーに公開しない理由になると思います。しかし、私にとっては、他の人がそのデータを見るために 2 つの用途があります。

状態データには基礎となるドメイン オブジェクトが含まれており、そのプロパティを使用して、要件が与えられたジョブを処理するのに最適な候補となるアクターを決定します。ジョブの要件は動的であるため、ワーカー アクターの個別のコレクションを持つことをためらっています (ただし、なぜ一時停止する必要があるのか​​はわかりません)。

他の前提条件を満たすすべての個別のアクターにクエリを実行し、すべての応答に参加するというアイデアは、非効率的であるか、少なくとも Akka にとって慣用的ではないように感じます。また、UI に現在の状態を表示する必要があり、同じイベント キューを使用して状態を表示する必要がある理由がわかりません。

とにかく、FSM にエージェントを更新させることを検討していましたが、それ自体がアクターであるため、その間接的な層が私に何をもたらすのかわかりません。イベントのシーケンスについての推論がはるかに難しくなる可能性があります。

Fowler の Event Collaboration は、状態データを明示的に送信することを私に指摘していますが、状態データを自動的に更新するすべての遷移に対してこれを行う簡単な方法を望んでいました。

また、イベント カスケードの順序付けと、それを制御する必要があるかどうかについて頭を悩ませています。すべての着信外部イベントが 1 つのアクターを経由する場合でも、内部で生成されたすべてのイベントを他のすべてのアクターに対して処理してから、次の外部イベントを処理する必要があります。セントラルコーディネーターに使ってもらいたいと考えていました!! 応答を待つ必要がありますが、イベント チェーンのどこかで感嘆符を誤って 1 つ削除すると、その保証が失われるのではないかと心配しています。

この問題に対して私が検討している解決策には、共有されるすべての「内部」アクターに対して単一のスレッド化されたディスパッチャー (おそらくワークスティーリングを使用) を使用して、内部イベントに高い優先度が与えられるように優先イベントを使用することが含まれます。

私がやろうとしていることに関連するベストプラクティスはありますか、それとも間違ったことをしようとしています:)?

STM パッケージを使用して並列マルチコア ブランチ アンド バウンド アルゴリズムを実装した課題のレポートを書いているところですが、直面した問題がありました。

STM を使用する実装は、STM の「アトミック」とコンカレントの「forkIO」の両方を使用するため、明らかに IO モナドにありますが、決定論的です。共有メモリ変数の使用にもかかわらず、関数の最終結果は常に同じ入力に対して同じになります。

私の質問は、「unsafePerformIO」以外に、IO から抜け出すためのオプションは何ですか? 複数のコアを使用すると、決定論に対して同じ保証がない他の並行コードに影響を与える可能性があるため、IOモナドからそれを取得しようとする必要があります。

Par モナド パッケージのことは聞いたことがありますが (使用したことはありません)、STM は IO モナドに存在し、スレッド セーフなグローバル変数を取得するために、STM に代わる唯一の方法は MVars (私が知っていること) です。 IO モナドにも存在します。

私はakka stmを使用しており、アプリケーションの起動時に (stderr に) 出力されます。

どうすれば無効にできますか (ロギング)?

STM トランザクションでスレッドが無期限にブロックされたと RTS が判断する時間間隔を増やす方法はありますか? これが私のコードです：

forkManagedは、同時に実行されるマネージド スレッドの数がmaxThreadsCountを超えないようにします。高負荷まで問題なく動作します。負荷が高い場合、RTS は例外をスローします。負荷が高く、リソースの同時競合が激しい場合、一部のスレッドは STM コンテキストにアクセスする時間がないだけだと思います。したがって、RTS がこの例外をスローすることを決定したときの時間間隔を長くすると、問題が解決する可能性があると思います。

Proguard を使用して Multiverse STM (0.6.2) に依存する Scala コードを最適化しようとしています。STM を akka と組み合わせて使用​​しています。そうしようとすると、次のエラーが表示されます。

次のフラグを使用して最適化しています。

この問題の回避策を知っていますか (明白な -dontoptimize 以外に)?

前もって感謝します！