「仕事中の食器洗い機」の問題に適用するアルゴリズムを探しています。
汚れたコーヒーカップなどを入れられるのは嬉しい反面、「食器はどうなっているの？」ジレンマ。キッチンに行ったら、食器洗い機から食器を取り出してもらえますか。汚れた皿を食洗機に入れることはできますか、それともきれいな皿が無効になりますか?
同等のプログラミングが必要な問題のようです。非同期的にトリガーされ、オブジェクトをある状態から別の状態に移動する共有プロセスがあります。いつでもオブジェクトの状態を知ることができる必要があります。どのようなアルゴリズムを適用できますか?
私の最初のオプションは、食器洗い機に「きれい」と「汚れ」のフリップフラグを作成することです。食器洗い機を空にするときは「汚れ」に切り替え、実行するときは「きれい」に切り替える必要があります。そのアルゴリズムに問題はありますか？より良い/エラーが発生しにくいものはありますか?
注: ポーリング スケジュールを利用するアルゴリズムはありません。
問題の主な問題は、スレッドが汚れたものをきれいな食器洗い機に入れUserたいときに発生します。Dish
解決策は簡単です。Dishwasher別のオブジェクトを作成します。
1 つDishwasherは汚れた皿を保持し、それらをきれいにするのを待っています。もう 1 つは最近洗浄した皿を保持します。
きれいな皿のDishwasher保持が空になったら、もう一方の汚れた皿を掃除し始めDishwasherます。
この時点で、スレッドは、以前はきれいだった (現在は空になっている)User汚れた皿を入れることができます。Dishwasher
Dishwashers2 つの役割を無期限に交互に続けます。Userスレッドは、KitchenCounterBuffer.
注: このソリューションでは、カップ不足の問題は解決されません。Userスレッドは、食器洗い機がクリーニングを完了するのを待ってブロックする可能性があります。
Dishwasher注 2:がシングルトンである制約のある環境では、 と を提供しKitchenCounterBufferて、DishwasherOperator食器を片付け、汚れた食器を から に置きKitchenCounterBufferますDishwasher。次に、上記のアルゴリズムでKitchenCounterBufferダーティの役割を果たします。Dishwasherただし、これにより、Userスレッドが例外をスローしたり停止したりする可能性があります。
プログラミングとは関係ありませんが、論理的な質問に答えるのに役立つかもしれません...私の食器洗い機には、洗濯機を走らせると点灯する「クリーン」ライトがあります。ドアを少し開けただけでも（つまり、きれいなカップを取り出すために）ライトは点灯したままになりますが、ドアを長時間開いたままにすると（洗濯機を空にするのに十分な時間）消灯します。完璧ではありませんが、 (やや物忘れしがちな) 人間がひっくり返さなければならない前面の旗よりもはるかに信頼性が高くなります。
食器洗い機から常にきれいな皿を取り除くというルールを作るだけです。そうすれば、=汚れているものはすべて、さらに追加できます。
見てください、これは手続き的思考の問題です。すべてをバッチ プロセスに変換しますが、これは非同期のイベント ドリブンの世界ではうまく機能しません。状態、スレッド、競合状態、永続性などについて心配する必要があります。
これらの問題を回避する解決策は、すべてのディッシュを不変にすることです。汚れた皿が必要な場合は、汚れを含む新しいインスタンスを作成するだけです。
料理のクリーンなコピーを取得することが一般的な操作である場合 (あなたの状況ではそうです)、.AsClean() メソッドを Dish オブジェクトに追加すると、自動的にクリーンなクローンが返されます。thisパフォーマンスがボトルネックになった場合は、インスタンスが既にクリーンである場合に戻ることで最適化できます。
もちろん、これは適切なヒープ スペースと自動ガベージ コレクションを備えた環境にいることを前提としています。
トンネルを通ってコンベヤーで皿を送る業務用食器洗い機を見たことがあります。汚れた食器は左側のラックに入れます。右側のラックからきれいな食器を取り出します。個々の皿のきれいな/汚れた状態は、マシン内の物理的な位置に対応しています。
これはまったく異なるアーキテクチャです。標準的な食器洗い機では、食器洗い機の属性として「きれい/汚い」を考えます。「きれい」とは「汚れた食器がないこと」を意味します。コンベア食器洗い機では、「きれい/汚い」は食器洗い機の属性ではありません。
このアーキテクチャに切り替えたくない場合もありますが、切り替える場合は、同時ブロッキング キューによって接続された一連の処理オブジェクトを検討してください。食器は、プレリンサーに入り、出てきて、洗濯機に入り、出て、乾燥機に入って、最後に出てきます。
私は、食洗機内のすべての物がきれいか汚れている必要があると仮定していますが、混ぜ合わせてはいけません. 以下のソリューションは、そのプロパティを強制します。そうでない場合、あなたの類推は正しくありません。
ほんの数個のミューテックスでうまくいくはずです。
4 つの状態があります。
違いを気にしないので、空と汚れを一緒にさらに折りたたむことができます。
これは、食器洗い機がいつ空になるかを知ることができることを前提としています。そうでない場合は、DirtyMutex を通知する前に待機する ElementsInDishwasher のカウント セマフォが必要になります。
私はあなたの例えが好きですが、根底にある問題が心配です。私の経験では、適切に設計されたシステムは、参照している状態の種類を常に (通常は暗黙のうちに) 認識しています。たとえば、共有リソース キュー内のリソースは、他のプロセスで使用できます。そうでない場合、リソースはキューにありません。または、ワーカー スレッドによって変更されているリソースは、スレッドの処理が示すどのような状態でもあります。さらに重要なことに、他のスレッドはそれが "クリーン" か "ダーティ" かを知る必要はありません。
私がまだ出会っていない (または発明した :-) 有効なデザイン パターンは気が遠くなるほどたくさんありますが、あなたが説明しているものには、有効なパターンではなく、デザインの匂い (または汚れた皿) のヒントがあります。
おそらく、 Finite State Machineはあなたが解決したい問題に適合するでしょうか?
洗浄サイクルの最後に、食器洗い機に食器を自動的に排出させることはできますか?
これは Mark Lutton のアイデアに似ており、きれいな皿を既知のきれいな皿の (おそらく一時的な) キューにプッシュし、そこからデキューすることに類似しています。
これは、崩壊しつつある技術の使用に起因する設計上の問題です。設計の一部をより高度な形に更新することで、問題全体を取り除き、時間、水、エネルギーを節約できます。
食べられるプレートを使用しますか？
これに対する簡単な解決策は、常に真である不変条件を維持することです。このような一連の不変条件の例は次のとおりです。
これらの不変条件を維持するのは、食器洗い機と相互作用するオブジェクトの仕事です。誰かが食器洗い機にカップを追加してそれがいっぱいになった場合、次の人が食器洗い機がいっぱいになり、すべてのカップがきれいであることを確認できるように、食器洗い機もオンにする必要があります。
あなたが示したように（クリーン/ダーティ）、フラグは1つだけ必要です。食器洗い機は通常、このメカニズムをすでに提供しています: (物理的な) ロックです。
ソフトウェア的な意味では、ロックは皿を食器洗い機に入れることができるかどうかのみにかかっています。取り出された皿がロックされているかどうかに基づいてきれいか汚れているかはわかりますが、そうでない場合にのみ皿を入れることができます。ロックされていません。最後の料理を取ると、ロックが解除されます。