What's the difference between:
Can something be both asynchronous and non-blocking (and event-based)?
What's most important in programming, to have something: asynchronous, non-blocking and/or event-base (or all 3)?
If you could provide examples, that would be great.
This question is being asked because I was reading this great StackOverflow article on a similar topic but it doesn't answer my questions above.
非同期 非同期は文字通り、同期していないことを意味します。メールは非同期です。メールを送っても、すぐに返事が来るとは思っていません。しかし、ノンブロッキングではありません。本質的には、「コンポーネント」がすぐに応答を期待せずにメッセージを相互に送信するアーキテクチャを意味します。HTTP リクエストは同期的です。リクエストを送信し、レスポンスを取得します。
ノンブロッキング この用語は主に IO で使用されます。これが意味することは、システム コールを実行すると、スレッドをスリープ状態にすることなく (高い確率で)、結果が何であれすぐに返されるということです。たとえば、非ブロッキングの読み取り/書き込み呼び出しは、できることは何でも返し、呼び出し元が呼び出しを再度実行することを期待します。たとえば、try_lock は非ブロッキング呼び出しです。ロックが取得できた場合のみロックします。システム コールの通常のセマンティクスはブロッキングです。read は、データが入るまで待機し、呼び出し元のスレッドをスリープ状態にします。
イベントベース この用語は libevent に由来します。ノンブロッキングの読み取り/書き込み呼び出し自体は役に立たない。select/epoll/IOCompletionPort などは、これらの呼び出しが「興味深い」データを返すことが「いつ」期待されるかを OS から検出するためのさまざまなメカニズムです。libevent などのライブラリは、さまざまな OS によって提供されるこれらのイベント監視機能のラッパーを提供し、オペレーティング システム間で動作する一貫した API を提供します。ノンブロッキング IO は Event-base と連携します。
これらの用語は重複していると思います。たとえば、HTTP プロトコルは同期ですが、非ブロッキング IO を使用する HTTP 実装は非同期にすることができます。ここでも、read/write/try_lock などの非ブロッキング API 呼び出しは同期的 (すぐに応答を返します) ですが、「データ処理」は非同期的です。
非同期ハードウェアでは、コードはエンティティに何かをするように要求し、アクションが完了している間は他のことを自由に実行できます。アクションが完了すると、エンティティは通常、何らかの方法でコードを通知します。ノンブロッキング アーキテクチャは、コードが関心を持っている可能性のある自発的に発生するアクションを記録し、コードがそのようなアクションが発生したことを確認できるようにしますが、コードはそのようなアクションについて明示的に質問した場合にのみ認識します。イベントベースのアーキテクチャは、イベントが自発的に発生したときに積極的にコードに通知します。
コードが 1,000 バイトを受信する必要があるシリアル ポートを考えてみましょう。
ブロッキング読み取りアーキテクチャでは、コードは 1,000 バイトが到着するか、あきらめることを決定するまで待機します。
非同期読み取りアーキテクチャでは、コードはドライバーに 1,000 バイトが必要であることを伝え、1,000 バイトが到着したときに通知されます。
ノンブロッキング アーキテクチャでは、コードは到着したバイト数をいつでも確認でき、必要に応じてそのようなデータの一部またはすべてを読み取ることができます。コードが 1/4 秒以内に 1000 番目のバイトが到着したことを知りたい場合は、約 1/4 秒ごとにチェックする必要があります。
イベントベースのアーキテクチャでは、シリアル ポート ドライバーは、データが到着するたびにアプリケーションに通知します。ドライバーは、アプリケーションが必要とするバイト数を認識できないため、アプリケーションは、アプリケーションが必要とする量よりも小さいまたは大きい量の通知を処理できる必要があります。
したがって、最初と2番目の質問に答えるには：
ノンブロッキングは事実上非同期と同じです。呼び出しを行うと、後で結果が得られますが、それが行われている間は別のことができます。ブロッキングはその逆です。旅を続ける前に、電話が戻ってくるのを待ちます。
Async/Non-blocking コードは非常に素晴らしく聞こえますが、実際にそうです。しかし、警告の言葉があります。Async/Non-blocking は、携帯電話などの制約のある環境で作業する場合に最適です...限られた CPU / メモリを考慮してください。また、コードが何らかの方法で UI ウィジェットに反応する必要があるフロントエンド開発にも適しています。
非同期は、すべてのオペレーティング システムがどのように動作する必要があるかの基本です。バックグラウンドで処理が行われ、要求された処理が完了するとコードが起動されます。呼び出しが失敗すると、処理が行われていないことが通知されます。例外、または何らかのリターンコード/エラーオブジェクトによって機能します。
コードが応答に時間がかかる何かを要求した時点で、OS は他の処理で忙しくなる可能性があることを認識しています。コード - プロセス、スレッド、または同等のブロック。コードは、ネットワーク接続が確立されるのを待っている間、または HTTP 要求からの応答を待っている間、またはファイルの読み取り/書き込みを待っている間、OS で他に何が起こっているかを完全に認識していません。すぐ。コードは、マウスのクリックを「単に」待機している可能性があります。その間実際に起こっていたのは、OS が「イベント」をシームレスに管理、スケジューリング、および反応していることでした。メモリ、I/O (キーボード、マウス、ディスク、インターネット) の管理など、OS が監視しているものです。その他のタスク、障害回復など。
オペレーティング システムはハードコアです。それらは、複雑な非同期/非ブロッキングのすべてをプログラマーから隠すのに非常に優れています。そして、ほとんどのプログラマーが今日のソフトウェアを手に入れた方法です。現在、CPU の限界に達しています。人々は、パフォーマンスを向上させるために物事を並行して行うことができると言っています。これは、非同期/非ブロッキングが非常に好ましいことのように思われることを意味します。はい、ソフトウェアが要求する場合は同意できます。
バックエンド Web サーバーを作成している場合は、慎重に進めてください。はるかに安価に水平方向にスケーリングできることを忘れないでください。ただし、Netflix / Amazon / Google / Facebook は、このルールの明らかな例外です。純粋に、使用するハードウェアが少ないほどコストがかからないためです。
非同期/非ブロック コードがバックエンド システムにとって悪夢である理由を説明します....
1) それは生産性に対するサービス拒否になります...もっと多くのことを考えなければならず、途中で多くの間違いを犯します。
2) リアクティブ コードのスタック トレースが解読不能になる - 何が、いつ、なぜ、どのように呼び出されたかを知るのは困難です。デバッグ頑張ってください。
3) 物事がどのように失敗するかについてもっと考えなければならない。古い世界では、一度に 1 つのことを行いました。
4) テストが難しくなります。
5) 維持するのが難しい。
6) 痛いです。プログラミングは喜びと楽しさであるべきです。マゾヒストだけが苦痛を好む。並行/リアクティブ フレームワークを作成する人はサディストです。
はい、同期と非同期の両方を書きました。バックエンド アプリケーションの 99.99 がこのパラダイムでうまくいくので、私は同期を好みます。フロントエンド アプリにはリアクティブ コードが必要であることは間違いありません。
はい、コードは非同期、ノンブロッキング、およびイベントベースにすることができます。
プログラミングで最も重要なことは、コードが動作し、許容できる時間内に応答することを確認することです。その重要な原則に固執すれば、間違いはありません。
私にとって、ノンブロッキングとは、スレッド内のアクションの実行が他のスレッドの実行に依存しないことを意味し、特にクリティカルセクションを必要としません。
非同期とは、実行が呼び出し元のフローの外で発生し、延期される可能性があることを意味します。通常、実行は別のスレッドで行われます。
同時データの読み取りは非ブロッキング (ロックする必要はありません) ですが、同期的です。逆に、同期的に同時にデータを書き込むことはブロッキングです (排他ロックが必要です)。メイン フローの観点からノンブロッキングにする方法は、書き込みを非同期にし、その実行を遅らせることです。
イベントの概念は別のものであり、大まかに言えば、何かが発生したときに通知されることを意味します。書き込みが非同期で実行された場合、書き込みが実行されると、システムの他の部分に通知するためにイベントを発生させることができます。他の部分はイベントに応答します。システムは、コンポーネント間で通信する唯一の方法 (アクター モデルを考えてください) として、イベントのみに基づいて構築できますが、必ずしもそうである必要はありません。
3 つの用語は関連していますが、私にとっては異なる概念です。ただし、人々は多少互換性のある方法でそれらを使用している可能性があります.
一般に、ノンブロッキング アーキテクチャはメソッド呼び出しに基づいており、ワーカースレッドで長時間実行される可能性がありますが、呼び出しスレッドをブロックしません。呼び出し元のスレッドが、ワーカー スレッドが実行しているタスクに関する情報を取得する必要がある場合、それを行うのは呼び出し元のスレッド次第です。
イベントベースのアーキテクチャは、発生したイベントに応答してコードが実行されるという概念に基づいています。通常、コード実行のタイミングは決定論的ではありませんが、イベントによってブロッキング メソッドが呼び出される場合があります。システムがイベントベースであるからといって、システムが行うすべてがブロックされていないわけではありません。
一般に、非同期アーキテクチャは、イベントベースのノンブロッキング アーキテクチャです。
非同期呼び出しが行われると、イベント ハンドラーが同期サービスを提供する API に登録され、呼び出し元が関心を持っていることが発生したことを呼び出し元に通知します。その後、呼び出しはすぐに返され (非ブロック動作)、呼び出し元は自由に実行を続行できます。イベントが呼び出し元のプロセスに返されると、そのプロセスのスレッドで処理されます。
イベントが同じスレッドで処理されるかどうかを理解することは重要です。これは、実行のノンブロッキングの性質に影響を与えるためです。
前述のとおり厳密には正しくないため、上記の段落を削除しました。私の意図は、OS 機能への呼び出しを行って実行を継続するなど、システム内の操作がノンブロッキングであっても、シングルスレッド実行の性質は、イベントが発生したときにそれらが競合することを意味するということでした。スレッドでの計算時間の他の処理タスク。