プロセスその19
ここまで説明したInterlockのメカニズムに比べると、Inter-Process/Thread Communicationに関しては一見あまり共通点はない。その最大の理由は、POSIX 1003.1への準拠を念頭においていたからということだろう。もともとProcess/Thread間通信に関しては、アプリケーションが多く利用する部分であり、これのためのインタフェースはWin16の時代、つまりWindows NT以前から提供されている。Win16 → Win32でいくらか追加された(これはPosix対応に関係する部分も多いが、OS/2の影響を受けた部分もある)が、これらとVAX/VMSの提供するInter-Process CommunicationのMethodは大幅に異なっており、これを持ち込む事は難しいと判断されたのだと思われる。実際、実装などは違っていても、出来ることは概ね等価(というか、当然Windowsの方が豊富)だから、無理に導入する必要は無かったというのが正確なところかもしれない。
ちなみになぜかInside Windowsの中にはプロセス間通信に関する章がない。恐らくは、これらのAPIはMSDNを初めとする様々な文献で十分に説明されているから、あらためて説明する必要はないと判断されたのではないかと思うが、ちょっとばかり残念である。折角なので簡単に触れておくと、Windows環境で利用できるInter-Process/Thread Communication Methodとしては、
- Semaphore/Mutex
- Metered Section
- Shared Memory
- WM_COPYDATA Message
- Memory Mapped File
- Event
- OLE(Object Linking and Embedding)
- Mail Slot
- Named Pipe
- Network DDE(Dynamic Data Excange)
- Windows Socket
- NetBIOS(Network Basic Input/Output System)
- RPC(Remote Procedure Call)
といったものが用意される。この他にもInter-Process/Thread Synchronization MethodとしてCritical Sectionがある。広義にはこれもCommunicationの一種かもしれないが、現実問題としてこれを使って通信するケースは無いと思うので、ここには入れていない。
これらのうち、Mail Slotから下はNetwork越しに他のマシン上で動くプロセスとも通信が出来るものである。当然同一マシン内のプロセス間での通信も可能であり、この特徴が必要なケースもある(ある処理をするのに、単一マシンでも複数マシンでも同じように動作することで、スケーラビリティを確保するといったニーズがこれにあたる)が、そうした要望がなければ敢えてこれを使ってわざわざオーバーヘッドを増やす必要はない。
またOLEは、その後Network環境で使えるNetwork OLEに進化し、これが最終的にDCOM(Distributed Component Object Model)に発展し、最終的に.NET Frameworkで置き換えられて廃れていった事もあって、現在ではあまり一般的ではない気もするが、その一方で未だに同一マシン内のプログラム連携にOLEが使われていたりするため、消えずに残っているのが面白いところだ。
さて、話をOS側に戻す。これらのInter-Process/Thread Communication Methodのうち、OS Kernel側で主にサポートが実装されているのは、
- Semaphore/Mutex
- Shared Memory
- Memory Mapped File
- Event
といったあたりだ。厳密に言えば、
- WM_COPYDATA Message
もClipboard Serviceを使っているから実装の一部はKernel内と言えなくも無いが、基本的にはKernelの外である。その他のものについては、もう完全にWindows Kernelの上で動くAPIレベルでの提供になっている。このあたりをまとめたのがこちらの記事、日本語版はこちらの記事だ。
