« マルチスレッド貧乏性(5) | Main | Emacs Threads 20161215 »

December 14, 2016

マルチスレッド貧乏性(6)

そろそろマルチスレッドをネタにした與太話も終わりにしないといけない。

マルチスレッドでソフトウェアを構成する目的は、極論すればコスパの追及に他ならない。噂によればGoogleのマシンルームにある膨大な數のサーバ羣は稼働率80%に達しているという。これはコンピュータの性能をほぼ100%引き出し、フルに活用していると言って良いのであろう。いい加減なサイジングで構築し、大して活用していないサーバなんて稼働率10%もいかない。そして、サーバ稼働率を上げる最善策がマルチスレッドプログラミングでないことくらい誰でも知っている。

マルチスレッドはコンピュータリソースを無駄なく活用するための一手段に過ぎない。さらに言えば、スレッドライブラリを活用して、複數のスレッドを制御しながら動くプログラムを書くことだけがマルチスレッドではない。スレッドライブラリというものが登場する以前から、UNIX上でのプログラミングにおいてマルチスレッドという槪念はあった。つまり、複數のプロセスを協調させて處理を構成する方法(マルチプロセス)である。

マルチプロセスはマルチスレッドに比べてソフトウェア的に安全であると言われている。マルチスレッドでは、1個のプロセス内で複數のスレッドがグローバル變數を共有するため、場合によっては意圖しない變數の書き換えや參照が發生し、潛在的な問題(瑕疵)が殘留しやすい。さらにスレッドセーフという言葉に集約される、固有のルール(再入などの問題對應)やプログラマのスキル、經驗値が品質を大きく左右する。それに比べてマルチプロセスでは、他のプロセスによる不用意な變更から保護されるので、プロセス閒インタフェースだけを意識してプログラムを書くことが出來る。

そもそもスレッド閒インタフェースなど有って無いようなものだ。そういう問題を覆い隱すために出てきたのが、機能とデータのカプセル化(いわゆるオブジェクト指向)であると思われるが、これについてはここでは觸れない。OOPはそのためだけにあるわけではない。

そういう意味で、これまでのGNU Emacsの實裝理念は正しかったと思う。必要なら複數のEmacsを起動し、相互に協調させたり、それらの處理がすべて終了するのを待つことなど、いくらでも可能である。少なくともスレッド閒のインタフェースを曖昧にしても構わないような方法より大いにマシと言わざるを得ない。今のところ、Emacsにおけるスレッド機能はかなり限定的であり、今後どうなるかは分からないが、一例をあげれば、letバインディングは起動した先のスレッドで參照不可である。スレッドライブラリの使用によりスタックが別になるならそれも當然と思われるが、そのためだからといって起動するスレッド每にグローバル變數が必要となるのはどうなんだろうという氣がする。しかし、それが數多くの既存の資產を守るためであれば致し方ない。現に一部のパッケージに影響が出ているという話もある。閒違っても、マルチスレッドを實現するために既存のlispコードをすべて書きなおすなんてことはあり得ない。

マルチスレッドする前に、マルチプロセスで可能か事前檢討する必要があるだろう。假にそのため1GB餘分にメモリが必要になったとしてもせいぜい數千圓(SE單金で1時閒分もしない?)もあれば濟むではないか(笑)

|

« マルチスレッド貧乏性(5) | Main | Emacs Threads 20161215 »

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/74224/64623645

Listed below are links to weblogs that reference マルチスレッド貧乏性(6):

« マルチスレッド貧乏性(5) | Main | Emacs Threads 20161215 »