hirax.net::Keywords::「スレッド」のブログ

■Rubyパフォーマンス総まとめ　

　Rubyパフォーマンス総まとめ：Heap Stackによる1.8.xのスレッドの高速化、MacRuby AOT、ZenProfileとEventHook

■ComThreadを使った「制御プログラムの作り方」図解編　

　以前、Rubyでテキストや（比較的単純低速な）バイナリデータ送受信のためのクラスであるComThreadを作りました（情報ページ）。それでは、どんな風に使うかということも、これまた以前、ComThreadを使った「制御プログラムの作り方」に書いたことがあります。

　ComThreadという名前が、実にありがちな名前であるので、他のライブラリともしかしたら混同されているのかもしれませんが、「送受信に2つのポートを必要とするのか？」という質問があったので、「そんなことはないですよ」とここに書いておきます（もしかしたら、最初に作成した際の紹介記事の2番目の例が、機器間のシリアル通信をモニタリングする例だったから、そういう風に勘違いされたかもしれません）。

　最初の記事の2番目の例、すなわち、機器間のシリアル通信をモニタリングする例は、AとBという機器間で行われている通信をモニタしたい、AとBは通常通り通信しあう関係にしたままで、その互いのやり取りを知りたい、という場合に、シリアル通信の内容を調べる、というプログラムです。つまり、簡略図にすると、A＜-＞Bという関係をA＜-＞PC＜-＞Bというにしてやり、PCはAから受信した内容をBに送り、Bから受信した内容をAに送るわけです。だから、PCからみると、機器Aへの接続を行うCOMポートと、機器Bへの接続を行うCOMポートの2つが必要だったというわけです。

　もちろん、それは2機器間の通信をモニタリングする例だったからで、（最初の紹介記事の）一番最初に挙げた例のように、１つの機器相手に送受信を行うだけであれば、当たり前のはなしですが、COMポートは1つしか必要としません。

　さて、これだけではつまらないので、今日は、ComThreadを使った「制御プログラムの作り方」で書いたことを図にしてみました。つまり、前回、文章とコードで書いた内容を「図」にしてみました。それが下の図になります。

　前回書いたように、（センサーやモーターといった）各ハードウェア機器に対するモデル・クラスをConThreadクラスを継承させて作り、また、制御を行うコントローラをThreadクラスを継承して作り、そのコンローラインスタンスに、各モデルのインスタンスを渡してやる、というのがComThreadを使い、複数機器を制御するのであれば、一番整理しやすいような気がします。

　つまり、（各ハードウェア）モデル・インスタンス（スレッド）を作成し、コントローラ・インスタンス（スレッド）を作成して、（各ハードウェア）モデル・インスタンスをコントローラ・インスタンスに渡した上で、必要な期間だけそれらのスレッドを動かしておく、というようなスクリプトを作る、という具合です。

■Windowsディレクトリが壊れて、「Rubyコード」になっていた。　

　Windows マシンで、ディスクの一部にアクセスできなくなりました。正確にいえば、ディレクトリにアクセスはできるのですが、そのディレクトリの中身が「ワケがわからない状態」になってしまっているのです。それが、下の画像です。

　何だか、とても奇妙な状態です。まるで、何やらRubyのコードのようなファイル・ディレクトリ名が並んでいる…ような気がします。このディレクトリには、Rubyのコードなどないはずなのですが、何やら、Rubyでスレッドを使って書いたシリアルポート制御プログラムが透けて見えるような気がする感じです。

　こういう現象というのは、一体どういう時に起きるものなのでしょう？そして、どうしたら、こんな現象を回避することができるのでしょうか？

　ディレクトリが壊れるたび、そのディレクトリが色んな言語の化身に変身したら「面白いだろうな」と少し思いおかしくなります。１時間ほど作業した内容がすべて消えたので、結構ショックなのですが、消えたファイル群が「Ruby プログラム」になっていたりしたので、少し楽しくなったのです。