離散イベントシミュレーション中のデキューメカニズムについて質問があります。
ほとんどの実装では、最も早いタイムスタンプでイベントをすばやく取得するために使用できる、ある種の優先キューを使用します。たとえば、実行するにはリソースが必要なため、このようなイベントをスケジュールできない場合はどうなりますか。
リソースでブロックされているイベントのタイムスタンプよりもタイムスタンプが大きい別のイベントがキューにある可能性があります。
たとえば、個別のチェックアウトラインとラインごとのレジ係を備えた食料品店をモデル化していると仮定します。チェックアウトラインに入る買い物客はイベントです。買い物客がチェックアウトラインに入った時間に基づいて、このイベントをキューに入れます。ただし、キャッシャーが別の順序で解放される可能性があるため、シミュレーションが2つのそのようなイベントを実行する順序は、必ずしもチェックアウトラインに入った時間の順序ではありません。
このようなシナリオでは、タイムスタンプのみに基づいて、リソースの可用性に関係なく、優先キューをどのように使用するのでしょうか。
シミュレーションで顧客の身元が重要でない場合は、レジ係ごとにキューを用意するか、少なくとも待機中の顧客の数を増やす必要があります（たとえば、フルトロリーを備えた1人のキューに、それぞれ1つのアイテムを含む3人のキューに参加します。したがって、キューの長さだけでは、そのヒューリスティックを組み込むために必要な情報をキャプチャできない場合があります）。
顧客がキューに参加すると、キューに入れている顧客の数が増えるか、顧客がレジ係のキューにプッシュされます。
レジ係がサービスを提供する準備ができると、最初の顧客がレジ係のキューからポップされます。したがって、カスタマーサービスイベントは、顧客が到着する時間ではなく、レジ係の準備ができる時間に依存します。
これらのキューまたはカウンターは、イベントのスケジューリングメカニズムから独立しています。スケジュールされたイベントはこれらのキューを操作し、スケジューリングのためにそれらに依存しません。
Pete Kirkhamが指摘したように、顧客が待機する行（キュー）は、イベントの順序を決定するために使用される優先キューとは完全に別のものであることに注意することが重要です。
離散イベントシミュレーションでは、イベントはシステム状態が変化する時点です。イベントが発生すると、状態に基づいて次に何をすべきかがわかります。顧客の列に加わることはイベントですが、サービスの対象になりつつあります。顧客がサービスを受ける資格を得ると、そのイベントのロジックは、サービスが可能かどうかをチェックする必要があります。その場合は、サービスが終了するときに新しいイベントをスケジュールします。リソースの制約がある場合、何もスケジュールされず、その顧客は保留になります。ただし、将来のある時点で、必要なリソースが利用可能になります。これもイベントであり、そのイベントのロジックは、リソースが不足しているために保留になっている顧客がいるかどうかを確認する必要があります。そうでない場合は、何もスケジュールする必要はありませんが、スケジュールする場合は、顧客の実際のサービスをスケジュールできます。
離散イベントシミュレーションがどのように機能するかについてのより完全な説明については、この入門チュートリアルペーパーを参照してください。