「プロセス間通信」の版間の差分
編集の要約なし |
|||
(同じ利用者による、間の21版が非表示) | |||
1行目: | 1行目: | ||
== IPCとは == | |||
プロセス実行中に他のプロセスと通信を行うための機構を考えます。通信ということでは2つの方法を挙げることができます。 | |||
* ローカルマシン内(もちろん動いているカーネルは1つという前提)で動作しているプロセス間での通信。 | * ローカルマシン内(もちろん動いているカーネルは1つという前提)で動作しているプロセス間での通信。 | ||
10行目: | 9行目: | ||
本章では前者のローカルマシン内での通信を取り上げます。もちろんローカルマシン内で動作するプロセス同士でもネットワーク経由と同じようにTCP/IPを使って通信できますが、本章のプロセス間通信の説明からはTCP/IPは除いておきます。 | |||
ここでのプロセス通信(InterProcess Communication / IPC ) | ここでのプロセス通信(InterProcess Communication / IPC )<ref> LinuxのIPCについては次の発表スライドが参考になります。 Michael Kerrisk, "An introduction to | ||
Linux IPC", linux.conf.au 2013 http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf </ref>とは、名前つきパイプ(named pipe)、pipe、UNIXドメインソケット(ローカルIPC)、 | |||
セマフォー<ref>Linuxのセマフォーに関しては次のWebサイトが詳しい。 http://www.linuxdevcenter.com/pub/a/linux/2007/05/24/semaphores-in-linux.html</ref>やあるいはシェアードメモリなどを指しています。これらにより高速にプロセス間でデータをやりとりするためのメカニズムと捉えます。Linuxでは、 | |||
System Vで使われていたプロセス間通信の機能、4.2BSDで採り入れられたソケット、名前つきパイプが使えます。 | |||
System Vで使われていたプロセス間通信の機能、4. | |||
;補足: | ;補足: 単一カーネル内ではIPのルーティング機能などの不必要な情報の付加や処理を行わずに済むので、その点から「高速にデータをやりとり」と書いていますが、経験的には、実際の速度差は実装によってずいぶん違うので、一概にどれぐらい違うかは簡単にはいえません。 | ||
== System V IPC == | == System V IPC == | ||
プロセス間通信の機能というと、System | プロセス間通信の機能というと、System Vで使われていたプロセス間通信の機能(System V IPC)のセマフォー<ref>セマフォーとは、元々は列車運行で列車が単線の区間に入ることを許されているか、あるいは待つのかを示す信号機なのだそうです。</ref>(semaphore)、メッセージキュー(message | ||
queues)、シェアードメモリ(shared memory)が有名です。 | queues)、シェアードメモリ(shared memory)が有名です。 | ||
ソフトウェアの世界では、複数のプロセスが同じ資源の競合を避けるために、使われる機能で、たとえば複数のプロセスが同時にファイルを書き込みするタイミングが同じになってしまわないように、セマフォを使って待ちます。 | |||
セマフォは(ファイルのロックなどを使うよりも)高速に処理できるので、たとえばデータベースのようなアプリケーションでの処理のロックなどに使われています。 | |||
しかし、同様な処理はmmapを使っても可能ですので、今日ではセマフォがなくては実装ができない、というわけではありません。むしろ、互換性のために残していると考えた方が良いでしょう。また今日ではSystem V IPCは、相対的に「重い」処理と考えられています。 | |||
一方、POSIX IPC はマルチスレッドで安全であり、かつ、System V IPCより軽量なのでPOSIX IPCの利用が推奨されています。<ref>IBMのdeveloper worksのサイトの中にある "[https://www.ibm.com/developerworks/jp/linux/library/l-semaphore/index.html System V のセマフォー API を使用して POSIX のセマフォー API を実装する]" の本文中に「POSIX のセマフォーは System V のセマフォーよりもはるかに軽量」という記述も存在する。</ref> | |||
57行目: | 38行目: | ||
System V IPCを使ってのメッセージキューは古いアプリケーションを動かすための互換性のために残されているようなもと考えても良いレベルになって来ています。今日では新規のプログラムに使うような場面を見かけたことがありません。最近ではメッセージキューを使う所を名前つきパイプで済ますことができます。シェアードメモリもmmapが使えます。 | |||
Linuxのカーネルが2.6以降ではPOSIX IPCが使えるようになりました。新しくプログラムを作る場合で、メッセージキューなどを使いたい時はSystem V IPCではなくPOSIX IPCを使うべきでしょう。 | |||
== POSIX IPC == | |||
TBD | |||
== 名前つきパイプ (named pipe) == | |||
現在のディレクトリにあるファイル数をカウントする | |||
その前にパイプを説明しましょう。コマンドラインでのシェルが持つパイプは、前のコマンドの標準出力を後ろのコマンドの標準入力にするというものです。使い勝手は、まるっきりファイルです。 | |||
現在のディレクトリにあるファイル数をカウントする | |||
<pre class="bash"> | |||
% ls | wc | % ls | wc | ||
</pre> | |||
このようなプロセス間で一方向に書き出し、読み込みをするプログラムを書く時は、UNIXの初期からあるシステムコールとしてpipe(2)を使って実現します。 | |||
pipe(2) は、プロセス中で2つの要素を持つファイルデスクリプタ配列に対して、1つは書き込み、もう1つは読み込みのディスクリプタを与えるというものです。このペアを作っておき、プロセスがフォークすると、1つのプロセス側は書き込み、もう一つのプロセス側は読み込みができるようになります。もちろん一方向にしかデータは流れません。 | |||
pipe(2) | |||
さて、名前つきパイプは、それまでのプロセスがフォークして資源を継承するしかできない一方向に流れるパイプとは違い、2つの完全に独立に存在しているプロセス間でデータをやり取りするために作られたものです。 | |||
FIFO(First-In-First-Out) | FIFO(First-In-First-Out)である名前つきパイプを作ります。これはファイルのように名前でアクセスできるFIFOの性質を持った双方向パイプを作ります。 | ||
まずコマンド mkfifo | まずコマンド mkfifo で名前つきパイプのファイルを作ります。ファイルといってもアクセスのために名前だけあって実態はパイプです。 ls -l で見ると先頭がpがあるので、名前つきパイプであることがわかります。あとls -Fとしてみると、npの後ろに"|"がついて出力されます。これは名前つきパイプ(FIFO) のファイルであるという意味です。 | ||
のファイルであるという意味です。 | |||
名前付きパイプのファイルを作る | |||
<pre class="bash"> | |||
$ mkfifo np | $ mkfifo np | ||
$ ls -l np | $ ls -l np | ||
107行目: | 79行目: | ||
$ ls -F np | $ ls -F np | ||
np| | np| | ||
</pre> | |||
この状態で2つのshellウインドウを開いてみてください。一つはnpを読む、もう一つではnpに書き込むことをしてみます。 | |||
shellウインドウ1 | |||
<pre class="bash"> | |||
$ cat np | $ cat np | ||
abcdef <-- 表示される | abcdef <-- 表示される | ||
123456 <-- 表示される | 123456 <-- 表示される | ||
$ <-- 終了する | $ <-- 終了する | ||
</pre> | |||
shellウインドウ2 | |||
<pre class="bash"> | |||
$ cat > np | $ cat > np | ||
abcdef <--入力 | abcdef <--入力 | ||
124行目: | 99行目: | ||
^D <-- ^Dで終了 | ^D <-- ^Dで終了 | ||
$ | $ | ||
</pre> | |||
ここでは判りやすいように一方向にデータを送っている例を出していますが、このようにファイル名でアクセスするようにしてプロセス間の通信が出来るというのは、実にUNIXらしいやり方です。プログラム中から名前つきパイプを作る時はユーザ関数 mkfifo(3)で作れます。 | |||
== UNIXドメインソケット (ローカルIPC) == | == UNIXドメインソケット (ローカルIPC) == | ||
これはTCP/ | これはTCP/IPネットワーク接続の機能のインタフェースと同じものを用意して、しかし、データはローカルなプロセス間通信に使おうというものです。元々はUNIXドメインソケットという形でBSD 4.xに組み込まれましたが、Posix はUNIXに依存しないのでローカルIPC という呼び方をしています。しかし、少なくとも筆者の知っている範囲のUNIXユーザはUNIXドメインソケットと読んでいるので、カッコつきで(ローカルIPC)としました。 | ||
;補足: | ;補足: POSIXでは「ローカルIPC」という呼び方をしますが、UNIX流ではUNIXドメインソケットと呼びます。 | ||
socket(2)、bind(2)、accept(2)のようにTCP/ | socket(2)、bind(2)、accept(2)のようにTCP/IPの通信を行うやり方は、TCP/IPが現れる以前のUNIXとはセマンティクス(意味的なもの)が違います。UNIXが、すべてを名前空間でアクセスしようとするのに対して、TCP/IP のような通信系のやり方は、一々、IPアドレスやポート番号を指定しなければいけません。 | ||
164行目: | 125行目: | ||
.... | .... | ||
ソケットをAF_LOCALで作成し、sun_familyをAF_LOCALに指定し、sun_path | ソケットをAF_LOCALで作成し、sun_familyをAF_LOCALに指定し、sun_path の部分にファイルパスを書きバインドすると、そのパスにファイルに見えるソケットが出来ます。こうすれば、あとのデータの送信/受信に関係するプログラムの構造はTCP/IPと同じに作れます。その面ではインターネット経由でアクセスするプログラムとローカルにアクセスするプログラムが同じ構造で作れる利点があります。 | ||
ログを出力するデバイスのように見せかけているソケット | |||
<pre class="bash"> | |||
$ ls -lF /dev/log | $ ls -lF /dev/log | ||
srw-rw-rw- 1 root root 0 Aug 23 14:13 /dev/log= | srw-rw-rw- 1 root root 0 Aug 23 14:13 /dev/log= | ||
</pre> | |||
これはログデーモンがオープンしているソケットです。しかしながら、パス名で見えていても、ファイルではないので、通常のファイルを扱うコマンドでアクセスしてもエラーになります。 | |||
かな漢字サーバWnnのソケットをcatで見てみる | |||
<pre class="bash"> | |||
$ ls -lF /tmp/jd_sockV4 | $ ls -lF /tmp/jd_sockV4 | ||
srwxr-xr-x 1 wnn nogroup 0 Sep 21 13:48 /tmp/jd_sockV4= | srwxr-xr-x 1 wnn nogroup 0 Sep 21 13:48 /tmp/jd_sockV4= | ||
$ cat /tmp/jd_sockV4 | $ cat /tmp/jd_sockV4 | ||
cat: /tmp/jd_sockV4: No such device or address | cat: /tmp/jd_sockV4: No such device or address | ||
</pre> | |||
これらはIPスタックを経由しません。IPは複数の独立したホストがあり、ネットワーク構築された世界をIPパケットが中継されていくモデルです。そのためにIPパケットを処理するためには、そのための処理がなされます。一方、UNIXドメインソケットには、そんな付加する情報をつけたり処理したりする必要はありません。よって高速に処理することが可能になります。 | |||
== 脚注 == | |||
<references/> | |||
---- | |||
[[目次]]へ | |||
このページへのショートURL: http://uc2.h2np.net/i/25.html | |||
2021年4月29日 (木) 15:05時点における最新版
IPCとは
プロセス実行中に他のプロセスと通信を行うための機構を考えます。通信ということでは2つの方法を挙げることができます。
- ローカルマシン内(もちろん動いているカーネルは1つという前提)で動作しているプロセス間での通信。
- ネットワークを経由して通信するネットワーク通信。
本章では前者のローカルマシン内での通信を取り上げます。もちろんローカルマシン内で動作するプロセス同士でもネットワーク経由と同じようにTCP/IPを使って通信できますが、本章のプロセス間通信の説明からはTCP/IPは除いておきます。
ここでのプロセス通信(InterProcess Communication / IPC )[1]とは、名前つきパイプ(named pipe)、pipe、UNIXドメインソケット(ローカルIPC)、
セマフォー[2]やあるいはシェアードメモリなどを指しています。これらにより高速にプロセス間でデータをやりとりするためのメカニズムと捉えます。Linuxでは、
System Vで使われていたプロセス間通信の機能、4.2BSDで採り入れられたソケット、名前つきパイプが使えます。
- 補足
- 単一カーネル内ではIPのルーティング機能などの不必要な情報の付加や処理を行わずに済むので、その点から「高速にデータをやりとり」と書いていますが、経験的には、実際の速度差は実装によってずいぶん違うので、一概にどれぐらい違うかは簡単にはいえません。
System V IPC
プロセス間通信の機能というと、System Vで使われていたプロセス間通信の機能(System V IPC)のセマフォー[3](semaphore)、メッセージキュー(message queues)、シェアードメモリ(shared memory)が有名です。
ソフトウェアの世界では、複数のプロセスが同じ資源の競合を避けるために、使われる機能で、たとえば複数のプロセスが同時にファイルを書き込みするタイミングが同じになってしまわないように、セマフォを使って待ちます。
セマフォは(ファイルのロックなどを使うよりも)高速に処理できるので、たとえばデータベースのようなアプリケーションでの処理のロックなどに使われています。
しかし、同様な処理はmmapを使っても可能ですので、今日ではセマフォがなくては実装ができない、というわけではありません。むしろ、互換性のために残していると考えた方が良いでしょう。また今日ではSystem V IPCは、相対的に「重い」処理と考えられています。
一方、POSIX IPC はマルチスレッドで安全であり、かつ、System V IPCより軽量なのでPOSIX IPCの利用が推奨されています。[4]
semget (2) - セマフォーの獲得 semctl (2) - セマフォーの制御 semop (2) - セマフォーの設定
System V IPCを使ってのメッセージキューは古いアプリケーションを動かすための互換性のために残されているようなもと考えても良いレベルになって来ています。今日では新規のプログラムに使うような場面を見かけたことがありません。最近ではメッセージキューを使う所を名前つきパイプで済ますことができます。シェアードメモリもmmapが使えます。
Linuxのカーネルが2.6以降ではPOSIX IPCが使えるようになりました。新しくプログラムを作る場合で、メッセージキューなどを使いたい時はSystem V IPCではなくPOSIX IPCを使うべきでしょう。
POSIX IPC
TBD
名前つきパイプ (named pipe)
その前にパイプを説明しましょう。コマンドラインでのシェルが持つパイプは、前のコマンドの標準出力を後ろのコマンドの標準入力にするというものです。使い勝手は、まるっきりファイルです。
現在のディレクトリにあるファイル数をカウントする
% ls | wc
このようなプロセス間で一方向に書き出し、読み込みをするプログラムを書く時は、UNIXの初期からあるシステムコールとしてpipe(2)を使って実現します。
pipe(2) は、プロセス中で2つの要素を持つファイルデスクリプタ配列に対して、1つは書き込み、もう1つは読み込みのディスクリプタを与えるというものです。このペアを作っておき、プロセスがフォークすると、1つのプロセス側は書き込み、もう一つのプロセス側は読み込みができるようになります。もちろん一方向にしかデータは流れません。
さて、名前つきパイプは、それまでのプロセスがフォークして資源を継承するしかできない一方向に流れるパイプとは違い、2つの完全に独立に存在しているプロセス間でデータをやり取りするために作られたものです。
FIFO(First-In-First-Out)である名前つきパイプを作ります。これはファイルのように名前でアクセスできるFIFOの性質を持った双方向パイプを作ります。
まずコマンド mkfifo で名前つきパイプのファイルを作ります。ファイルといってもアクセスのために名前だけあって実態はパイプです。 ls -l で見ると先頭がpがあるので、名前つきパイプであることがわかります。あとls -Fとしてみると、npの後ろに"|"がついて出力されます。これは名前つきパイプ(FIFO) のファイルであるという意味です。
名前付きパイプのファイルを作る
$ mkfifo np $ ls -l np prw-r--r-- 1 hironobu hironobu 0 Dec 16 21:58 np $ ls -F np np|
この状態で2つのshellウインドウを開いてみてください。一つはnpを読む、もう一つではnpに書き込むことをしてみます。
shellウインドウ1
$ cat np abcdef <-- 表示される 123456 <-- 表示される $ <-- 終了する
shellウインドウ2
$ cat > np abcdef <--入力 123456 <--入力 ^D <-- ^Dで終了 $
ここでは判りやすいように一方向にデータを送っている例を出していますが、このようにファイル名でアクセスするようにしてプロセス間の通信が出来るというのは、実にUNIXらしいやり方です。プログラム中から名前つきパイプを作る時はユーザ関数 mkfifo(3)で作れます。
UNIXドメインソケット (ローカルIPC)
これはTCP/IPネットワーク接続の機能のインタフェースと同じものを用意して、しかし、データはローカルなプロセス間通信に使おうというものです。元々はUNIXドメインソケットという形でBSD 4.xに組み込まれましたが、Posix はUNIXに依存しないのでローカルIPC という呼び方をしています。しかし、少なくとも筆者の知っている範囲のUNIXユーザはUNIXドメインソケットと読んでいるので、カッコつきで(ローカルIPC)としました。
- 補足
- POSIXでは「ローカルIPC」という呼び方をしますが、UNIX流ではUNIXドメインソケットと呼びます。
socket(2)、bind(2)、accept(2)のようにTCP/IPの通信を行うやり方は、TCP/IPが現れる以前のUNIXとはセマンティクス(意味的なもの)が違います。UNIXが、すべてを名前空間でアクセスしようとするのに対して、TCP/IP のような通信系のやり方は、一々、IPアドレスやポート番号を指定しなければいけません。
int sockfd; struct sockaddr_un addr; ... sockfd=socket(AF_LOCAL, SOCKET_STREAM,0); ... addr.sun_family = AF_LOCAL; strcpy(addr.sun_path, "/tmp/mysocket"); bind(sockfd,&addr,SUN_LEN(addr)); ....
ソケットをAF_LOCALで作成し、sun_familyをAF_LOCALに指定し、sun_path の部分にファイルパスを書きバインドすると、そのパスにファイルに見えるソケットが出来ます。こうすれば、あとのデータの送信/受信に関係するプログラムの構造はTCP/IPと同じに作れます。その面ではインターネット経由でアクセスするプログラムとローカルにアクセスするプログラムが同じ構造で作れる利点があります。
ログを出力するデバイスのように見せかけているソケット
$ ls -lF /dev/log srw-rw-rw- 1 root root 0 Aug 23 14:13 /dev/log=
これはログデーモンがオープンしているソケットです。しかしながら、パス名で見えていても、ファイルではないので、通常のファイルを扱うコマンドでアクセスしてもエラーになります。
かな漢字サーバWnnのソケットをcatで見てみる
$ ls -lF /tmp/jd_sockV4 srwxr-xr-x 1 wnn nogroup 0 Sep 21 13:48 /tmp/jd_sockV4= $ cat /tmp/jd_sockV4 cat: /tmp/jd_sockV4: No such device or address
これらはIPスタックを経由しません。IPは複数の独立したホストがあり、ネットワーク構築された世界をIPパケットが中継されていくモデルです。そのためにIPパケットを処理するためには、そのための処理がなされます。一方、UNIXドメインソケットには、そんな付加する情報をつけたり処理したりする必要はありません。よって高速に処理することが可能になります。
脚注
- ↑ LinuxのIPCについては次の発表スライドが参考になります。 Michael Kerrisk, "An introduction to Linux IPC", linux.conf.au 2013 http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf
- ↑ Linuxのセマフォーに関しては次のWebサイトが詳しい。 http://www.linuxdevcenter.com/pub/a/linux/2007/05/24/semaphores-in-linux.html
- ↑ セマフォーとは、元々は列車運行で列車が単線の区間に入ることを許されているか、あるいは待つのかを示す信号機なのだそうです。
- ↑ IBMのdeveloper worksのサイトの中にある "System V のセマフォー API を使用して POSIX のセマフォー API を実装する" の本文中に「POSIX のセマフォーは System V のセマフォーよりもはるかに軽量」という記述も存在する。
目次へ
このページへのショートURL: http://uc2.h2np.net/i/25.html