2

ファイルのようなブロック デバイスのコンテキストでは。提供された I/O 操作のキュー内でio_submit()のみ非同期のような Linux カーネル AIO 関数であるか、同じファイルに対する I/O 操作のキューを持つ複数のプロセスおよび/またはスレッド間で (また) 非同期です。

Doc によると: io_submit()システム コールは、AIO コンテキスト ctx_id で処理するために nr 個の I/O 要求ブロックをキューに入れます。iocbpp 引数は、コンテキスト ctx_id に送信される nr 個の AIO 制御ブロックの配列である必要があります。

アップデート：

例: 2 つのスレッドを生成した場合、両方とも同じファイルに対して 100 のキューに入れられた I/O 操作を持ち、両方ともio_submit()約 1 秒で呼び出します。同時に; 200 の I/O 操作はすべて非同期になりますか、それともスレッド #1 の 100 の I/O 操作は互いに非同期であるだけで、スレッド #1 のすべての I/O 操作が完了するまでスレッド #2 をブロックしますか?

4

2 に答える 2

1

アプリケーションが気にする必要がある非同期動作の唯一の部分は、アプリケーション内にあります。はい、アプリケーションの実行中のある時点で、他のプロセスもディスクにデータを書き込む可能性があります。マルチタスク、マルチユーザー、および潜在的にマルチプロセッサのシステムでそれを止めるためにできることはほとんどありません。

readここでの一般的writeな考え方は、アプリケーションがブロックされないということfreadですfwrite。

他のプロセスが「あなたの」ファイルに触れないようにしたい場合は、ファイルロックなどを使用する必要があります。

于 2013-04-15T09:21:05.200 に答える
0

一連の io 要求が で送信されるとio_submit、システム コールはすぐに戻ります。リクエストを発行するスレッドの観点からは、リクエストに埋め込まれたコマンドの実行は非同期です。スレッドは結果を知るために OS にクエリを実行する必要があり、その間は自由に実行できます。

ここで、2 つのスレッドがたまたま一連の要求をそれぞれ発行した場合、それらは両方とも同じ状況に陥ります。どちらも、それぞれの IO コマンドの進行状況について OS に問い合わせる必要があります。ブロックされるスレッドはありません。

AIO フレームワークの観点からは、それを呼び出したいずれかまたはすべてのスレッドの呼び出しから戻る前io_submitに、OS に実際に要求を実行させることは完全に可能ですが、API は同じままです。ユーザーランド スレッドは引き続き API を非同期のものであり、API がリクエストを投稿するときに API から将来の結果のトークンを取得し、そのトークンを使用して実際の結果を取得します。

Linux AIO の特定のケースでは、トークンは事前に作成されたコンテキストであり、結果チェック syscall はio_getevents、完了したリクエストごとに「イベント」(つまり、結果) を報告します。

あなたの例に関して、2番目のシステムコール中に、最初のスレッドのすべてのリクエストが完了する可能性はありますか? これがまったく起こらない理由はわかりませんが、両方のスレッドが 100 件のリクエストを非常に近い間隔で投稿する場合、その可能性は非常に低いと思われます。より可能性の高いシナリオは、最初に呼び出すスレッドのいくつかの要求がio_submit、2 番目のスレッドが に対して独自の呼び出しを行うときに完了したio_submitが、いずれにせよ、その呼び出しがブロックされないというものです。

于 2013-04-15T10:37:10.310 に答える