並行処理の奥義、非同期フレームワークとは？

　メモリ管理、非同期フレームワーク、クライアントサーバ、これらのコンセプトが

• マイクロカーネルOS
• C++によるシームレスなオブジェクト指向環境

により統合されている。これがSymbian OSの特徴であるということを、これまでの連載で説明してきました。

　連載も進み、外堀も埋まってきたということで、いよいよSymbian OSの3大ポイント（図1）の2番目にして多くの誤解の源泉、非同期フレームワークの解説を行いたいと思います。誤解とは穏やかならざる表現ですが、この連載を行うきっかけになったのが、まさにこの誤解の多さでした。

図1　Symbian OSの3大ポイント

　ご存じのとおりC++では（Cでも同じですが）、並行処理に対する規定がありません。この部分に関しては、それぞれの実行環境ごとに異なったライブラリが用意されます。つまりC++／Cで書かれているからといって、並行処理に関してはポータビリティがないのです。常識？ そう、まさに常識に属する話だと思うのですが、なぜか多くのソフトウェアエンジニアはほかのOSへの引っ越しに際して、それまでの環境と同じ並行処理モデルが通用するはずだ、という根拠のない期待を持つようです（注1）。それはSymbian OSへの引っ越しにおいても例外ではないようで、第1回に記した「アレがないシンドローム」のかなりの部分を、この並行処理に関する誤解が占めるようです。

　つまり今回のゴールは、各環境から引っ越してきた人がSymbian OSの並行処理に対して抱く誤解を解くことにあります。以下、順を追って進めていきましょう。

ブロッキング再考

　マルチタスク環境におけるシステムの応答性を考えるとき、ブロッキングのことを避けて通ることはできません。

図2　同期型APIのシーケンス図

　図2にあるように、せっかく複数の実行コンテクスト（注2）を用いてシステムを構成したとしても、要求が完了するまで待つ設計では意味がありません。ブロッキング期間には外部からのイベントを受け取ることができないため、システムの応答性を確保できなくなってしまいます。

　例えばPOPサーバに対して新着メールを取りに行く、という処理を図2中の［サービスプロバイダ1］に委譲したとします。最初のブロッキング区間には、

• コネクション確立（場合によっては回線接続が）
• POPサーバとの認証処理
• 実際のメールデータの取得処理

など、一切合切が含まれることになります。その期間［クライアント］はどのようなイベントに対しても反応することができません。ブロッキング区間にメール一覧を送信者のアドレス順に並べ替えようとしたとすると、いったいどんなプログラム構成にすればよいのでしょう。ブロッキング区間は操作が一切止まることにしますか？

　しかしそれでは避けられない話があります。例えばメールの受信中断はどうやって指示をしたらよいのでしょうか。よくある長時間ブロッキング対策は、以下のようなものでしょう（筆者もWindowsでプログラムを書いているときには、こんなことをやったような……）。

• 中断のキーシーケンスをホットキーとして登録しておき、発生した時点で［サービスプロバイダ1］のしかるべき関数を呼び出すというシグナルモデル
  これはUI（ユーザーインターフェイス）にかなりの制限が付きます。
• キャンセルのダイアログを別の実行コンテクストで表示させておき、そこに対して中断指示が発生しなかったか［サービスプロバイダ1］がチェックしに行くというポーリングモデル
  この場合［サービスプロバイダ1］がUIを持つ（少なくとも知る）という構造上のひずみが発生します。

　どちらの方法も同期APIを基本としてとらえたうえで、キャンセルを例外的に処理しようとするため、システム構成に制約や問題が発生しています。