問題タブ [state-machine]

Windows ワークフローのステート マシン ワークフローを使用する予定です。

ステート マシンは 2 つの別々のスレッドからイベントを受け取ります。ステート マシンはもちろん、現在の状態と入ってきたイベントに基づいて状態を変更し、アクションを実行します。

私の質問は、Windows ワークフロー スレッド セーフのステート マシンですか。つまり、2 つのスレッドが同時にアクセスしたときに正しい状態変更が保証されるということですか?

デフォルトでノンブロッキング I/O を備えた Qt フレームワークを使用して、複数の Web ページ (オンライン ストア) をナビゲートし、これらのページでさまざまなアクションを実行するアプリケーションを開発しています。特定の Web ページを、このページをナビゲートするために使用するステート マシンに "マッピング" しています。
このステート マシンには次の遷移があります。
Connect, LogIn, Query, LogOut, Disconnect
そしてこれらの州。
Start, Connecting, Connected, LoggingIn, LoggedIn, Querying, QueryDone, LoggingOut, LoggedOut, Disconnecting, Disconnected
*ing 状態から *ed 状態への移行 ( Connecting->Connected) は、LoadFinished現在要求されている URL が読み込まれたときにネットワーク オブジェクトから受信した非同期ネットワーク イベントによるものです。*ed から *ing 状態 ( Connected->LoggingIn) への遷移は、私が送信したイベントによるものです。
このマシンにいくつかのイベント (コマンド) を送信できるようにしたい (Connect、LogIn、Query("productA")、Query("productB")、LogOut、LogIn、Query("productC")、一度に処理してもらいます。マシンに送信したすべてのイベントの処理が完了するのを待つことをブロックしたくありません。問題は、ダウンロードされている URL についてマシンに通知する上記のネットワーク イベントとインターリーブする必要があることです。*ing から *ed への進行は、ネットワーク タイプのイベントを受信した後にのみ行われるため、インターリーブがないと、マシンはその状態を進める (およびイベントを処理する) ことができません。

どうすれば設計目標を達成できますか?

編集

1. 私が使用しているステート マシンには独自のイベント ループがあり、イベントはキューに入れられないため、マシンがビジー状態のときにイベントが発生すると、マシンによって見逃される可能性があります。
2. ネットワーク I/O イベントは、使用しているステート マシンにもイベント キューにも直接ポストされません。それらは私のコード (ハンドラー) に投稿され、私はそれらを処理する必要があります。希望通りに転送できますが、備考欄にご注意ください。1.

3. 現在の設計を詳細に説明したこの質問に対する私の回答を見てください。問題は、このデザインを作成することで、このデザインを改善できるかどうか、またどのように改善できるかです。

   • より堅牢
   • よりシンプルに

ステートマシンを作成し、Javaのジェネリックを利用したいと考えています。現在、私はこれを機能させて見栄えの良いコードを取得する方法がわかりません。この設計の問題は以前にも何度もアプローチされていると確信しており、いくつかの入力を探しています。ここに大まかな概要があります。

各個別の状態オブジェクト（ほとんどの場合、静的最終変数に関連付けられた匿名クラス）のコピーが1つだけあり、各状態のカスタムデータがあります。各状態オブジェクトには状態の親があります（ルート状態は1つです）

各メッセージは個別に作成され、各メッセージにはカスタムデータがあります。それらは互いにサブクラス化する場合があります。ルートメッセージクラスが1つあります。

各ハンドラーは1回だけ作成され、特定の状態/メッセージの組み合わせを処理します。

State現在、現在の状態と、すべての（ 、Message）->Handlerマッピングのリストを追跡します。他の機能もあります。私はこのクラスをジェネリックに保ち、プログラムで何度も使用され、毎回異なるセットのMessage's / State's/とHandler'sを使用して、型パラメーターでサブクラス化しようとしています。が異なるStateMachineと、ハンドラーに対して異なるパラメーターが使用されます。

アプローチA

ステートマシンにすべてのマッピングを追跡させます。

この特定のステートマシン用のカスタムハンドラーメソッドを使用できます。handler.processメソッドのパラメーターは上書きできます。ただし、ハンドラーをメッセージタイプでパラメータ化することはできません。

問題：これにはinstanceof、各メッセージハンドラーの健全性チェックの使用が含まれます（期待するメッセージを取得していることを確認してください）。

アプローチB

各メッセージハンドラーをメッセージタイプごとにパラメーター化できます

問題：MessageHandler型消去では、すべての型が異なるため、これらを適切なハッシュマップに格納できなくなります。それらを地図に保存できれば、それらを取得して適切な議論で呼び出すことはできません。

アプローチC

状態オブジェクトにすべてのメッセージを処理させます。

私はメッセージハンドラーを特定のステートマシンの状態に（それらを内部に置くことによって）結び付けています（ステートマシンの各インスタンスには有効な状態の独自のリストがあります）。これにより、ハンドラーを特定のタイプにすることができます。（サーバーステートマシン->サーバーメッセージハンドラー）。

問題：各状態は1つのメッセージタイプしか処理できません。また、親の状態が子の状態とは異なるメッセージを処理できるという考えも失われます。型消去は、StateMachineが現在の状態のプロセスメソッドを呼び出さないようにします。

アプローチD

状態に基づいてメッセージ自体のプロセスを設定します。

問題：各メッセージは現在のステートマシンの状態に基づいて異なるハンドラーを持つ必要があるため、実際には考慮されません。送信者は現在StateMachineの状態を知りません。

アプローチE

ジェネリックスと、switchステートメントを使用したハードコードの状態/メッセージ処理については忘れてください。

問題： 正気

安全でない解決策：

みなさんのご意見ありがとうございました。問題は、これを良い問題に還元しなかったことだと思います（議論が多すぎます）。

私は現在、可能な状態の更新を毎分数回送信する数千のオブジェクトの状態を並行して追跡する必要があるシステムを扱っています。さらに、追加の計算を実行する必要があります (CPU を使用するだけで、遅い IO はありません)。

現在、カスタム ステート マシンの実装を使用しています。ただし、WF はシステムの他の部分で使用されるため、WF ステート マシンは少数 (<5) の状態を持つシナリオに適しているのではないかと思います。

パフォーマンスに関しては、オーバーヘッドが大きすぎるのではないかと心配しています。MS のドキュメントは WF ステート マシンのパフォーマンスに関するトピックを実際にはカバーしていないため、一部の SO メンバーが WF ステート マシンのパフォーマンスに関する情報またはリソースを持っているのだろうか?

よろしくj。

ステート マシンを開発するためのインターネット上の優れたチュートリアルを誰かが知っているかどうか疑問に思っています。それとも電子ブック？

私はステートマシンの作業を始めていますが、始めるには一般的なものが必要です。

状態が非常に少ないリアルタイムシステムのステートマシンがあります。

ただし、これらの州間の移行にはかなりの時間が必要であり、独自の細分化があります。したがって、2つの選択肢があります。メインのステートマシンを拡張して、すべての中間状態が表されるようにします。

または、関連するメイン状態のネストされたステートマシンを作成します。

どちらの可能性にも長所と短所があります。大きなステートマシンは非常に簡単に乱雑で複雑になります。ただし、2番目のケースですべての状態を一貫させることも簡単ではなく、多くの関数はグローバル状態とサブ状態の両方に関する情報を必要とします。

次のようないくつかの並列状態を処理する必要がある複雑なコードは避けたいと思います。

このような問題に対する一般的な最善のアプローチは何ですか：多くの小さくネストされたステートマシン（多くの無効な組み合わせを持つ）、1つの大きなステートマシンまたは他のもの？

私はいくつかの一般的なものを探しています

1. 最適化
2. 正しさ
3. 拡張性

現在のC++階層ステートマシンの実装に関するアドバイス。

サンプル

実装

現在、HSMはツリー構造として実装されており、各状態は子として可変数の状態を持つことができます。

各状態には、基本値をオーバーライドする可変数の「オーバーライド」ブロック（std :: map内）が含まれています。ルート状態では、ステートマシンには、いくつかのデフォルト値に初期化された一連の変数（関数、プロパティなど）があります。子状態に入るたびに、「オーバーライド」のリストによって、親状態の同じ名前の変数と値を置き換える必要がある変数と値が定義されます。わかりやすくするためにオリジナルを更新しました。

変数の参照

実行時に、現在の状態はスタックに保存されます。

変数が参照されるたびに、下向きのスタックウォークが実行され、最も高いオーバーライドが検索されます。オーバーライドがない場合は、デフォルト値が検索されます。

状態の切り替え

単一の状態フレームが切り替わるたびに、状態はスタックにプッシュされます。

状態が切り替わるたびに、現在の状態からルート状態に移動するツリーの下降をトレースします。次に、現在のトレースが前のトレースと一致することがわかるまで、ターゲット状態からルート状態へのツリーの下降を実行します。これらの2つのトレースが出会う場所で交差点を宣言します。次に、ターゲット状態に切り替えるために、ソースから降りて、交点に到達するまでスタックから状態フレームをポップします。次に、ターゲットノードに昇格し、状態フレームをスタックにプッシュします。

したがって、上記のコードサンプルの場合

状態切り替えの実行トレース

• ソース状態=記録

• ターゲット状態=alsoStreamToRemoteIp

• ソースからの降順=記録->ルート（トレース= [ルート]）

• ターゲットからの降順=alsoStreamToRemoteIp->playingback-> root（trace = [playback、root]）

• ルートで交差します。

記録からalsoStreamToRemoteIpに切り替えるには、

1. スタックから「記録」をポップします（そしてその終了関数を呼び出します...ここでは定義されていません）。
2. 「再生」をスタックにプッシュします（そしてenter関数を呼び出します）。
3. 「alsoStreamToRemoteIp」をスタックにプッシュします（そしてenter関数を呼び出します）。

ステート マシンの開発と実行、およびメッセージ/シグナルの受け渡しをサポートするネイティブ (FSM 生成ツールがない) 言語の推奨事項。これはテレコム用です。たとえば、このレベルの複雑さの FSM の実装などです。

私は Erlang を検討しましたが、フィードバック、提案、チュートリアルへのポインタ、代替案、特に Java ベースのフレームワークを歓迎します。もしかしてスカラ？

オープンソースのみ。UML や正規表現に関連するソリューションは探していません。

これは通信プロトコルの実装のためのものであるため、FSM は自明ではない可能性があります。多くの状態、多くの遷移、信号ベース、入力制約/ガード。動的なインスタンス化はプラスになります。switch ステートメントは問題外です。すぐにネストして使用できなくなります。if/else よりもかろうじて優れています。

グラフィックデザインに依存したくない。形式の FSM 記述は、人間が判読可能/編集可能/管理可能でなければなりません。

--

C++ のアクター ベースのソリューションに集中することにしました。

たとえば、Theron フレームワークは開始点http://theron.ashtonmason.net/を提供し、FSM ベースのイベント ハンドラーで switch ステートメントを回避するには、この C++ FSM テンプレート フレームワークが役立ちますhttp://satsky.spb.ru/articles/ fsm/fsmEng.php

ステート マシンを使用して、wiki マークアップなどの単純な文法を解析したいと考えています。私はそれを書いたり遊んだりしたことがありません。簡単なものを実装する方法を学びたいと思います。これにはClojureを使用することを考えています。私の質問は、私の自己など、このトピックに関する完全な初心者向けの優れたチュートリアルをいくつか教えてもらえますか?

特定のモデルの状態のコレクションにアクセスすることは可能ですか:

クラス 会話含む AASM

終わり

次のような状態の配列を取得できるようにしたいと思います。

これは可能ですか？