並行処理の奥義、非同期フレームワークとは？：Symbian OS開発の勘所（6）（2/3 ページ）

Symbian OSでは「アクティブオブジェクト」という非同期処理の機構を用いて、マルチタスク環境におけるシステムの応答性を確保している

[大久保 潤 管理工学研究所，＠IT MONOist]

非同期処理という発想転換

　UI対応処理は［クライアント］に、メール取得処理は［サービスプロバイダ1］に、それぞれ集約できれば見通しの良いシステム構成になるのですが、上記の方法ではそうはなりません。ここで前提を変えてみます。すべての処理は非同期で行われるとすると、図2のシーケンスはどのように変わるでしょうか。

　非同期処理の場合、要求通知の延長で行われる処理は、処理の登録（キューイング）だけです（図3中（A）の期間で処理）。そのため［クライアント］にはごく短時間で復帰することになります。［クライアント］はいつか完了が通知されることを期待して、外部からのイベントを待つ状態、ウェイトに移行します（図3中（B）の期間）。完了通知もイベントを通じて行われることに注意してください（図3中（D）のイベント）。

図3　非同期型APIのシーケンス図

　しかしこの期間は別に［サービスプロバイダ1］からの完了通知だけを待っているわけではありません（注3）。ほかのイベントが入ってくれば、［クライアント］はそれに応じた処理を行うことができます。図3においては［サービスプロバイダ1］の処理にオーバーラップして、［サービスプロバイダ2］に対して要求を発行しています（図3中（C）の期間）。非同期APIをベースに考えると、応答性の良いシステムを構築できることがお分かりでしょうか。

※注3：

このように単一のイベントだけを待つウェイトを、シングルウェイトといいます。タイムアウトなしでシングルウェイトを行うことは、ブロッキングを発生させることと等価です。

　さてここでキャンセルの取り扱いを考えてみましょう。［クライアント］は外部からのイベントを自由に待つことができます。要求完了までの期間ブロッキングが発生しないためであり、かつ完了通知を拾う必要があるためでもあります。もちろんキャンセルの指示も何らかのイベントを通じて行われるので（ダイアログのボタン押下も、中断のキーシーケンスもイベントです）、ウェイトを通じて拾うことができます。このシーケンスを以下に示します。

図4　非同期型APIにおけるキャンセルのシーケンス図

　イベントを受けて（図4中（E））、キャンセル要求を［サービスプロバイダ1］に発行しています。このシーケンスでは、UI対応処理は［クライアント］に、メール取得処理は［サービスプロバイダ1］に、というすみ分けができています。おお、非同期APIをベースに考えると

• システムの応答性
• UI対応処理と要求処理の分離

などがきれいに実現できるではありませんか。

I/Oのブロッキング

― ちょっと待って。図4の（F）のところ、どうして［サービスプロバイダ1］はキャンセル要求を受け取ることができるの？ ―

　するどい突っ込みです。［クライアント］は非同期APIを使うことによって、ウェイトを細かく出せるようになりました。同じことが［サービスプロバイダ1］にも起きています。

　［サービスプロバイダ1］が提供するサービスは「POPサーバに対して新着メールを取りに行く」でした。すると［サービスプロバイダ1］では要求を受けた後、ネットワークに対していくつものI/Oを発行しているはずです。このI/Oがすべて非同期であれば、［クライアント］同様、［サービスプロバイダ1］もブロッキングすることなく、外部からのイベントを待てることになります。キャンセル要求はこのようにして［サービスプロバイダ1］に受理されたと考えることができます。

― I/Oが非同期？ ―

　そうです。要求の延長でI/Oが完了しないタイプの処理です。I/Oの完了は別途待つ必要がありますが、その代わりブロッキングを避けられるという重要な利点があります。

　実は多くのOSにおいて非同期I/O用のAPIが用意されています。ファイルI/O、ネットワークI/Oについて代表的なOSでどのようなサポートが行われているか、以下に示します。

OS名	ファイルI/O	ネットワークI/O
Windows系	・同期が標準 ・ReadFileEx()、WriteFileEx()などEx系APIを使用することで非同期処理を行う	・同期、非同期兼用API ・WSAOVERLAPPED構造体を指定することで非同期処理を行う
POSIX系	・同期が標準 ・aio_xx()という非同期APIが用意されている ※select()が提供するものは、完了通知の検出ではなくreadyの検出なので、非同期APIには含めない
T-Kernel／SE	・同期のみ	・規定なし
Symbian OS	・非同期が標準 ・疑似的に同期に見せるAPIあり
表1　代表的なOSの非同期I/Oサポート

　このようにシステムの最下層に位置するI/Oまで非同期に扱えるのであれば、図3、図4で示したような、

1. ブロックしない、応答性の良いシステムを
2. UIと処理を分離した適切な構造で

実現できます。そしてSymbian OSでは上記I/Oに限らず、すべての処理は非同期で構成されています。

　ただしどんな話にも付帯条項は付きものです。非同期をベースにしたシステム構成は、全員が対応して初めて意味を持ちます。誰かが同期型のデザインを行えば、そこでブロッキングが発生してしまいます。今回の場合「ただし」は、

全員が必ず非同期型のデザインを行えば

ということになります。