プロセスとスレッド~後編

皆さん、こんにちは。Dr.テトランです。

前回のプロセスとスレッド~前編を踏まえた上で、そろそろ現実のOSの話を始めたいと思います。

Version3.1xまでの古いWindowsと異なって、それ以降のOSは各実行モジュール単位に独立したプロセスを割り当てています。具体的なCPUを想定する必要がありますので、以降はインテルのi386以降とします。i386はセグメントアーキテクチャを駆使することで64TBの仮想空間を扱えますが、MSでは(1セグメントに固定の)フラットメモリモデルにして、4GBの仮想メモリをプロセスに割り付けます。

これは、OSをインテルアーキテクチャに特化することなく、他のCPUも考えた結果でもありますが、この4GBの制限はそろそろ問題になりつつあります。アプリケーション実行に割り付けれられた4GBの仮想空間は、OSとアプリケーションで二分して、使います。このときNT系と9x系ではOS側の使い方に決定的な違いがあります。NT系では、その部分にはWin32Subsystemが載るだけで、肝心のOS本体は保護された別プロセスで動作しています。そして、Win32サブシステムはLPCを使ってWindows NT Executiveを呼び出しています。

今、あるファイルを複数のプロセスで共有することを考えます。別の節でも述べたようにファイルにアクセスするには多くのニーモニックを使いますので、その間他のプロセスからのアクセスを全てカットしておく必要があります。

例えば、アクセスする度に、排他オープン/クローズを繰り返します。しかし、ファイルを変更する場合は、先ず読み取っておいてから、処理した結果を書き込むのが普通ですから、その間排他オープンされたままですので、無関係なレコードへのアクセスもブロックされてしまいます。また、関連するファイルが複数の場合はさらに面倒を引き起こしてしまいます。そうでなくても、排他オープンしたプロセスがトラブったり、ネットワークに問題が生じた場合に他のプロセスが影響を受けてしまい、データの安全性も危うくなってしまいます。

これが、1台のコンピュータで複数のプロセスであれば、ミューテックスのようなプロセス間同期オブジェクトを利用することで、もっとスマートな解決法がありますが、そもそも異なるコンピュ-タの場合は、そのような訳にはいきません。一番の解決策は、各々のプロセスを二つに分けて、ファイルを操作する部分を、そのファイルが在るコンピュータに持ってくることです。更に、それらのプロセスを一つのプロセスにまとめてDBMSにしてしまえば、プロセス間の同期も必要ありません。但し、元々別のプロセスであったものは、それぞれの片割れと通信する必要があるわけですから、個々に仮想CPUを割り振る必要があります。

それがスレッドです。部分プログラムの実行単位と思ってください(実はその下にファイバーがあります)。このようにすれば、同期オブジェクトもプロセス内であるため、オーバーヘッドを小さくすることができます。手荷物の授受も簡単です。勿論、二分したプロセス間の通信機能が必要で、Tetra21ではRPCを使っています。こちらの実現法は既に述べたとおりです。

 

Comments are closed.