セマフォ＋共有メモリを捨て高水準ITCへ：Symbian OS開発の勘所（9）（2/3 ページ）

プリミティブなAPIに固執する態度を改め、必要に応じて高水準のITCを使うことが「車輪の再発明」を廃絶する近道だ

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

ITCをデザインするパーツは何か？

　従来の組み込み向け設計とは、極論すると、

• 実体………………プロセス（スレッド）
• 排他メカニズム…セマフォ（ミューテックス）
• 共有資源…………共有メモリ

の3種類のパーツを組み合わせて、システムに対する要求を機能分割、時間分割していこうというアプローチでした。しかしこれらプリミティブを直接意識してシステム設計を行うのは、アセンブラでプログラムを書くことは是か非か、という設問と相似です。双方とも、

1. それでなければ実現できない
2. 実現しようとしている仕様の範囲と記述方法の間のギャップが小さい

のいずれかを満たすような案件でなければNGとなる性質を持っていますから。

　では逆に考えてみると、設計に関する高級言語相当のものは何なのでしょうか。ツールによる方法、理論による方法（注2）、いろいろなアプローチがありますが、忘れてならないのはモデルのカタログ化です。典型的なパターンを用意することによって、毎回再発明することを避け、生産性を向上させるというのがデザインパターンの目的ですが、これはITCに関しても有効です。クライアントサーバ・フレームワーク自身もITCに関するパターンの実現と見なすことができますし、いまから解説するITCの機構も同様です。図2にそれらを示します。

図2　マルチタスクにかかわる諸要素 − 完全版

※注2：

ROOM法やOCTPUS法など。それからExecutable UMLもリアルタイム上等といってましたね。

ITCのデザインパターン − ワンショット型

　パターンという視点でクライアントサーバ・フレームワークを振り返ってみます。これが実現しようとしているモデルは、

キューを介して、1要求に対して1完了を返す、非同期関数呼び出し

でした。このモデル、ワンショット型のメリットは、

1．双方とも状態管理が楽（取りこぼしが起きにくい、キャンセルがしやすい）

2．クライアントから見て、通信路に滞留するメッセージが高々1

3．キューが存在するので、複数クライアントからの要求がシリアライズされる

などです。これで充足する要求であれば、車輪の再発明など行わずに素直にクライアントサーバ・フレームワークを使いましょう、というのは前回解説したとおりです。

　逆にワンショット型に向かない要件にはどのようなものがあるでしょうか。

ITCのデザインパターン − マルチキャスト型

　例えばSMSが到着したことを、ワンショット型のITCを使って複数のアプリケーションに同報通知することを考えてみましょう。クライアント側からすれば通知依頼を発行するだけですが、サーバから見るとかなり面倒な話になります。キューの中に入っているすべての要求をスキャンしないと「いま発生したSMS到着イベント」に対する通知を適切に行うことができません。

　しかもクライアント側にしても、本当に興味があることはイベントの発生であって、それを通知してくれるサーバを意識するのは単なるコストです。このような要求

1．1つの事象を複数のエンティティから観測したい

2．しかも通知を行う側のエンティティのことを意識したくない

を満たすパターンをマルチキャスト型といい、Symbian OSではこのパターンの実装を「パブリッシュ＆サブスクライブ」（発行と購読）という機構で提供しています（図3）。

図3　パブリッシュ＆サブスクライブ

　パブリッシュ＆サブスクライブでは事象を観測する側をサブスクライバ（購読者）、事象を通知する側をパブリッシャ（発行者）と呼びます。クライアントサーバと同じく利用者と提供者が存在しますが、

・1つの通信路についてサブスクライバとパブリッシャの関係はn：1になることができる

（クライアントサーバは複数の通信路を持てるが、それぞれの中は1：1の関係）

・どのスレッドもAPIの発行だけでサブスクライバ、パブリッシャそれぞれになることができる

（クライアントサーバでは、サーバはしかるべきクラス階層の中に位置する必要がある）

などの相違点があります。

　事象の通知に用いる通信路として、パブリッシュ＆サブスクライブではプロパティと呼ばれるシステムグローバルな変数を使います。変数がなぜ通信路になるかといえば、図3にあるとおり値の変更が発生するたびに登録されている全サブスクライバ（購読者）に対し、変更通知が発生するからです。このようにパブリッシャ（発行者）はしかるべきAPIを用いてプロパティに値を書き込むだけ、サブスクライバ（購読者）は指示があったらプロパティから値を取得するだけ、というプログラムを書くだけでマルチキャスト型の通信ができるようになっています。

　具体的には下記表1にあるAPIを用いてプログラムを構成します。一点強調しておきたいことは、一度作成したプロパティは明示的に削除するか、それともOSがリブートするまで消えないということです。消し忘れはそのままリソースリークにつながるので注意が必要です。

操作名	動作
定義（define）	作成し、その型とIDを定義する
削除（delete）	システムから削除する
発行（publish）	値を変更する
取得（retrieve）	現在の値を変更する
購読（subscribe）	変更通知を受けられるように登録する
購読解除（unsubscribe）	登録を解除する
表1　プロパティ操作用API

　このようにSymbian OSでは、マルチキャスト型のパターンをパブリッシュ＆サブスクライブという簡潔なセマンティクスで提供しており、マルチキャスト型のITCに関しても、もはや再発明は不要となっています。