非同期IO

非同期I/O (英: asynchronous I/O) とは、入出力の処理を、その要請元のプロセス・スレッドとは独立に（非同期に）行う、入出力のAPIの類型である。

概要

ブロッキング・非ブロッキングとの違い

非同期I/Oはほぼ必ず非ブロッキングI/O (non-blocking I/O) であるため、非常にしばしば混同されるが、同期 or 非同期と、ブロッキング or 非ブロッキングという分類は、必ずしも一致しない。POSIX環境において、O_NONBLOCKが設定されたファイル記述子に対して通常のreadやwriteを行うと非ブロッキングになるが、それは「ブロックされるようであればエラーにする」という動作になるのであって、非同期になるのではない（たいていのI/O操作はOS内のバッファなどによって、同期型のAPIでもブロックすることなく完了できることも多い）。ディスクに実際に書き込まれるまでを待つかどうか、という観点での同期・非同期もあるが、それはここで扱っているものとは別の話である（詳細は文献等の、フラグ O_DSYNC, O_DIRECT についての記述や英語版記事 en:Raw device などを参照のこと）。

非同期I/Oとは、

バッファの内容が、カーネル等によってコピーされるか、あるいはプログラマの責任で処理が完了するまで要求元のプロセスがそれを保持しなければならない
（権限違反など、即座にカーネルがエラー等にできる場合を除き）入出力の成否も、入出力を要求するシステムコールの結果としては得られず、コールバックか、別のシステムコール等で改めて得る必要がある
以上のような制限の下に、入出力要求のシステムコールはブロックせず、最小限の処理ですぐに終了する

といったようなスタイルの入出力APIによるI/Oである。よって非同期I/Oが利用されるのは、「時間制約の厳しいRTOSだから」といったような理由ではない。排他制御の都合などでブロックさせられないとか、あるいは、性能上の理由ではエンタープライズ用途で欲されることもあれば、イベントドリブン型のフレームワークであるために必要であるといった場合もある。別スレッドを使うことで、プロセス内で非同期I/Oのように見せかけるライブラリ（フレームワーク）といったものもあり得る。

実装

Linuxでは、POSIX-XSI、POSIX 1003.1bあるいはio_uringの実装が行われている。

Windowsでは、Windows NT系列 (Windows NT 3.1以降) の全てのバージョンで実装が行われている。

使用方法

基本的な呼び出し方法は、以下のステップである（前提とするAPIによって異なる。ここで示すのは一例）。

実行するシステムコールの内容をリンクリストで記述する。
リンクリストをパラメータとして、非同期システムコールを発行する（呼び出す）。
エラーあるいは、終了しているかどうかを、問い合わせるシステムコールを発行する。
終了待ちシステムコールを発行するか、既に発行したシステムコールをキャンセルするシステムコールを発行する。

組込型RTOSやミニコンピュータでの実装は、非同期システムコール発行時に、システムサービスコールをOSの処理として行うが、UNIXやLinuxの処理では、ユーザースレッドとして処理を行っている実装が多い。

下記の例では、lio_listio(...);に続いて、aio_suspend(...);を実行しているため、実質的にwrite()と同じになる。

Linuxでのサンプルプログラム

Windows

Microsoft Windows環境では、Windows NT 3.1以降の全てのディスクI/O、Winsock (バージョン2.0以降) などのWindows APIに非同期バージョンの関数がいくつか用意されている。例えばReadFileやWriteFile APIは、OVERLAPPED構造体に非同期I/Oのための現在のコンテキストを保持し、結果を待機するためのカーネルシグナルオブジェクトを指定することができる。

より高度な実装を行う場合は、これらのシグナルオブジェクトとスレッドを動的に管理する「I/O完了ポート」を利用し、最適なワーカースレッド数の制御とI/OオフロードをAPIレベルで実現できる。

非同期プログラミング環境

コールバックなどを利用した非同期I/Oの結果の取得は、設計やプログラミングが煩雑になる。特に出力よりも入力で問題が大きい。非同期I/Oに限った話ではないが、一般的な非同期処理を記述する「非同期プログラミング」を容易にするために、ライブラリや言語構文によるサポートが用意されているプログラミング環境もある。

ライブラリによるサポートは、例えばJava 1.5にて標準化されたFutureや、C 11にて標準化されたstd::async/std::futureなどがあり、これらはスレッドベースのFutureを実現する。.NET Framework/.NET CoreではC#などの.NET言語から利用可能なタスク並列ライブラリ (Task Parallel Library, TPL) が、またMicrosoft Visual C の同時実行ランタイムではC から利用可能な並列パターンライブラリ (Parallel Patterns Library, PPL) が用意されている。さらにこれらを発展させたものとして、C# 5.0/VB.NET 11以降や、Python 3.5以降にはasync/await構文が用意されている。なお、F#には非同期ワークフロー (asynchronous workflow) と呼ばれる、TPLとは異なる独自のインフラを利用した非同期プログラミングのための機能が備わっている。C ではC 20にてco_await構文が標準化された。

JavaScriptはシングルスレッドで動作するため、非同期プログラミングはイベント駆動ベースの疑似的な手法に頼らざるを得なかったが、Web Workerによってマルチスレッドプログラミングがサポートされるようになった（Web Workerのスレッドではメモリ空間を共有せず、実際にはメッセージベースのマルチプロセスプログラミングとなる）。そのほか、ECMAScript 2015 (ES2015) ではPromiseが、ES2017ではasync/await構文が標準化された。