RTOSのタイマーの問題(結論)

画像 簡単に説明すると、 記事の内容を説明します



たとえば、秒をカウントする周期的なハードウェアカウンターがあり、オーバーフローのための割り込みがあります。 割り込み内の別のセルの値を増やして、ソフトウェアによって数値範囲を拡大します。 したがって、カウントと分を取得する機会が得られます。 問題の本質は、一般的な場合、分と秒の値を同時に読み取ることは不可能であり、連続読み取り中に分が中断および増加する可能性があることです。 結果:タイムトラベルバック。



例:1分20秒、分を読み取ります。 50秒間続く中断があり、分が増分されます-

2分10秒、読み取り秒。



時間を取得します:1:10(1分10秒)、1:20で測定を開始し、結果が2:10であったため、時間を遡って初めてそのような時間を取得できました。 (著者が主張するように)読み上げでは、分というカテゴリに遅れているため、このような読み上げシーケンスを実行することはできません。これは、対応するカテゴリに収まるすべての秒よりも常に大きいためです(1分遅れはマイナス1分、秒プラスのみで1分以内)。



最初の秒、次に分を読むと、逆に1分程度の未来の時間を与えることができ、過去へのフライトはキャンセルされます。



したがって、基準は、読み取り時間は論理的なように見える関数の開始時間と終了の間でなければならないという考えによって記述され、これに基づいて、すべての推論が構築されました。 同時に、読み取り秒数と分数の値との対応のために勇敢に戦いましたが、これは非常に簡単ではありません。一般的なケースでは、カウンターが非常に迅速にカウントされるか、システムに大きな負荷がかかるため、関数の実行中に多数の長い中断が発生するこれは「分」が変化します(わかりやすくするために、従来はこの分と呼びます) 分はカウントされなくなります(この場合、分はプログラムでインクリメントされます)ため、中断を禁止することはできません。これはすでに完全なハルマゲドンです。



既知の秒が正しい分に対応していることをどのように確認できますか? 私たちがすべてを非常に迅速に行い、幸運だったことを望んでいるので、数分、数秒、そして数分後に中断することはありませんでした(テスト読書)、またはそれは非常に速く、その分は期限切れになる時間がありませんでした。 これは簡単に確認できます。議事録のテスト値は同じ値になるはずです。 しかし、最悪の場合、そのような状況の組み合わせを無限に取得しようとするため、結果が得られません。



元の記事では次のように方法が考案されました:1回だけチェックし、分が変更された場合、変更されたと仮定します。つまり、分と秒をすばやく読み取るために59秒も残っていることを意味します。女性に。 実際には、このような手法は非常にうまく機能しますが、理論的にはこれはまったく解決策ではありません。なぜなら、59秒は保証されておらず(70のすべての割り込みをすぐに取得できます)、再び秒と分を読み取り、一般的に、それは同じ犯罪によって破壊されます。 しかし、統計的に-はい、このようなヒューリスティックを使用して、誤ったデータの確率を大幅に削減しました。



著者のコメントでは、彼らは本当の道を指図し、それは非常に簡単です。 私たちは実際に必要なものから抽象化しすぎており、実際には解決策を必要としない特定の球面同期の問題を解決しようとしています。



私は説明します:「今何時ですか」を見つけるために関数を実行します。すぐに答えられたら、すぐにでも数秒に興味があるかもしれません-実際の目的のためにミリ秒を使うことができます。 彼らが1時間以内に私たちに答えたら、何ミリ秒あるかはまったく関係ありません。1時間よりも正確に「現在の」時間を測定することはできませんが、前述のように、それでもタイムトラベルは許容されません。



したがって、非常に単純なアルゴリズムが提案されます。



分を読み、秒を読み、分の読みをテストし、すべてが正常であれば、結果を返します。 分が変更された場合、現在の時間はn分00秒以降ですが、59秒以下であり、ほとんどの場合は数秒です。これは、著者の経験則のように、ある分から別の分への移行の近くにいる必要があるためです。 私たちのタスクは、できるだけ早く(n分00秒)この結果を返すことです。同期、読み取り、または再確認の試行は、作業の中断によって終了する場合があります(最悪の場合、終了するはずです)。現在の時刻から離れて、次の値を悪化させます。同期の時間と比較して、どれだけ正確であったとしても、そうではありませんでした。



したがって、00秒の戻り値は、実際の読み取り値よりもさらに正確です(読み取り秒数と追加のチェックに時間を浪費しません)。同期が可能になった時刻ではなく、「今」の時刻を取得するためです。 実際、ランダムに取られた時間はいずれも私たちに適しています。主なことは、関数の稼働時間の間隔内にあり、関数自体ができるだけ機能しないことです。 これはまさにあなたが非常に正確な仮定をすることを可能にする発見的方法であり、それは間違いなく関数の間隔に該当します。



批判:さまざまな方法で時間を使用できます。「今」を2回取得して間隔を測定しようとすると、「アラーム」を待つと、このようなアルゴリズムで最小のエラーが発生します。 ある時点で開始したい場合、たとえば、同じ場所で規定されているリアルタイムに正確に対応するログファイルのエントリが直後に続く場合は、パルスを失うか、より洗練されたものが見つかるまで同期するのが理にかなっているかもしれませんしかし、私にとっては、これはまったく別のタスクです。



もちろん、秒の統計分布を台無しにして、00の可能性を高めたため、Randomizeのようなものには副作用があります。



All Articles