これはスレッドの場合は100％正常です。すべてのオペレーティングシステム。スレッドライブラリのドキュメント、見つけることができる例、チュートリアルなどはこれを強調します。これは、人々がスレッド方法を学ぶときにしばしば混乱を招く可能性があるためです。

スレッドがデフォルトです（定義に従って）。同期しない。

これは、ロック、セマフォなどを介して反対方向に配置しない限り、スレッドが特定の順序で実行されることを期待しないことを意味します。 彼らが何をしているのか、どうするのかは関係ありません。考える彼らが何をしているのかなどによって「起こることもあります」。 簡単に言えば、それらをこのように考えないでください。それは彼らの存在でもなく、彼らの目的でもありません。 「私はシングルユーザーモードになっていて、システムを水のように静かに作ろうとしています。なぜなら…たぶん、あえて」のような考えを思い出すのは時間の無駄で、学ぶことはありません。 。水は避けられないまだではない、液体はそうです。物語の終わり。続けてお楽しみください。

あなたが言ったように、ほとんど何もしないように設定したシステムでほとんど何もしないスレッドがあると、スケジューラの負荷が減りますが、CPUはまだ最高速度で実行されており、ほとんど何もしないことがすぐに発生することに注意してください。状況は必ずしも他のどの状況よりも予測可能なわけではありません。 スケジューラは、スレッドとプロセスの順序を同期的または予測可能に指定するように設計されていません。 私は私が言うことがあなたがより複雑で医師論理的な実験をするようにインスピレーションを与えないことを心から願っています。なぜならすでに言ったように、時間の無駄です。続行してください。

あなたできるそしてそれらを同期させることが可能です。しかし、これは彼らが「自然に」しない理由を最初に理解するように要求する微妙なトリックであることに注意してください（手がかり：彼らはそれをする理由がないのでそれをしません）。

「決定論的なオペレーティングシステムを作成する理由〜らしい不確実性？ 」

おそらく、流体力学のたとえ話は最終的にそれほど愚かではないかもしれません。体液〜らしいカオス - 煙が生きているようです。私は数学、流体力学、カオス理論の研究を信じています。クロス。しかし、ほとんどの人はおそらくこれにショックを受けません（「素晴らしい！自然現象で何がそのような行動を引き起こす可能性がありますか？おそらくそれは神の証です！」…いいえ）。 ) 流体力学と相互作用)特定の範囲内で観察おおよその予測が可能な結果（「良い、水がガラスのガラスから注がれる...」）が生成されるので、実際には混乱しているか不確実です（テーブルに水が飛び出すパターン）。ただ「非常に小さな火」や水の一杯でも、私たちはその動きに何兆もの粒子が関与していることを認識しています。

コンピュータがどれだけ早く計算できるかを確認するためにカウンタを繰り返しながら忙しく見たことがある場合は、次の順序であることがわかります。数十億1秒あたりの回数。 「アイドル」システムでも引き続き発生するほとんどの「マイナー」システムイベントは、印刷IDでアクティビティが測定されるスレッドよりもはるかに重要であることに注意してください（そうであれば）すべてのスレッドが実行中。流動的な比喩によると、「完全に風のない」日だと思う日でも、煙はまだ秩序ある柱を形成しません（ただし、自分の動きが煙にどのように影響するかをより明確に見ることができます）。

スケジューラは、各プロセスに一度に正確に1ナノ秒を提供するのではなく（これにより実験をより予測可能にすることができます）、すべてのプロセスがバランスの取れた方法で実行されるようにする必要があります（重力による水の溢れる可能性があります）。スケジューラの役割は何も同期するのではなく、すべてが適切にバランスの取れた方法で発生するようにすることであるため、これはすべて大丈夫です。これら2つの目標は同じではありません。実際に同期を開始すると、同期は確実なバランスを取ることができますが、効率が悪くなることがわかります。

さらに、Linuxスケジューラは次のものを使用します。レッドブラックツリーキューを整理するには、ペイロ行（現代の汎用スケジューラがこれを行うかどうか疑問です）。これは意味するより大きな複雑さしたがって、確かに混乱した行動。

私はあなたが執着に固執することを奨励したくありませんが、スレッドにもっと実用的なタスクを実行するように頼むと、実際にスレッドに次のようなタスクを実行させます。時間これを実行し、アイドルシステムで数秒の時間オフセットを置いて実行すると、実際に完全に決定的な結果を見ることができます。 これだけ覚えてくださいいいえ本当に効果的な同期手段 --風が吹いて水が溢れるとカオスが始まるのがわかります;)

「これらのイベントがオペレーティングシステムのスケジューラに与える影響を調査した研究をご存知ですか？」

いいえ、液体のような神秘的なものはまったくありません。スケジューラは実際には完全に決定的ですが、検討中の意味や規模ではありません。カーネルコードに多くの情報を入れてprintkスケジューラのアルゴリズムを理解すると、不確実性が見つかりません。すべてが期待どおりに発生します。

ソフトウェアはハードウェアよりも決定的ではありません。まず、さまざまなソース（マウス、キーボード、ネットワーク、時計、ストレージ、OSバックグラウンドタスクなど）からランダムに割り込みが発生します。

プログラムの実行中にこれらの割り込みが完全に無効になっても、80486および最新の汎用x86デスクトップハードウェアはかなり非決定的な実行順序を持ちます。 （したがって、通常は多くのリアルタイム作業には適していないため、Pentium 1と2がリリースされてから80386が2007年に生産され続けています。）合理的なコストでスループットを得るには、ハードウェア決定論を犠牲にする必要があります。これは、キャッシュ効果、同時マルチスレッド（ハイパースレッド）、分岐予測、非順次実行、およびパイプライン化によって引き起こされます。決定論的な動作は、8ビットArduinoがはるかに速いRaspberry-Piよりも正確な機械制御に適している理由です。

デフォルトでは、Mainline Linuxは、インタラクティブな操作のための優れた総スループットと優れた平均レイテンシを達成するように設計された汎用スケジューラを含む汎用オペレーティングシステムです。メインラインは、待ち時間の制限と適切な順序を必要としますが、まれに発生する予期しない状況を可能にするビデオ通話などの「ソフトリアルタイム」予約で使用することもできます。

完全にプリエンプティブなハードリアルタイムLinuxカーネルを作成するためのリアルタイムパッチがあります。 （カーネルスレッドもユーザーの操作のためにプリエンプション/遅延/中断することができます。）これにより、ジョブの待ち時間をバイアス制限に制限できます。ハードウェア。これらの厳しい制限要件は、しばしばハードウェアの有効活用を減らし、オペレーティングシステムの動作を変更する。 （これは駐車場でいくつかの駐車スペースを予約するのと同じです。最大平均車数は減りますが、駐車スペースを予約するユーザーには駐車時間が固定されています。） 。取引、精密センサーデータサンプリング、医療機器などのハードウェアの選択は、開発の考慮事項の重要な部分です。特に、必要な最大（平均、中央値、またはモードではない）遅延分散（総遅延ではない）が約500,000クロックサイクル未満でなければならない場合は、さらにそうです。

一般的な汎用Linuxスケジューラの場合。ジョブのデフォルトのスケジューリングは、CPUの負荷と実際のジョブの動作に基づいて実行時に優先順位をわずかに調整する動的優先順位を使用します。実際のCPUのロードとジョブの動作には、バックグラウンドジョブ、さまざまな起動状態（たとえば、実行開始時のキャッシュ条件）、およびランダムエラー（たとえば、ジョブが勝利または敗北させる偽の割り込み要求）のために多くの変数が含まれます。レース）。次のタイムスライスとそれに応じたスケジューリングカスケード効果。 )

私は8ビット初期からPCを使用してきましたが、多くのプログラミング言語に精通しています。私はMint Cinnamonのオペレーティングシステムが動作する必要があることを実行した後、バックグラウンドでオペレーティングシステムのより深い機能を台無しにすることができることを何度も見つけました。再起動は通常役に立ちますが、必ずしもそうではありません。結局のところ、Windowsは優れていませんが、システムが提供する変更オプションを変更した後に何が起こるのかをより予測可能であると言うべきです。過去のテストに慣れているので、Mintは正しい方法でテストされていないと思います。