In message <199912271458.XAA14143 / dsmtp0.dion.ne.jp>
m_seki / mva.biglobe.ne.jp writes:

> dRubyをつかって なんちゃってLindaもどき を書いてみました。
> いまマシンが一台しかないので並列処理の実験まではできないので
> ほんとにうまく並列処理できるか自信がないのですが
> もしよろしければ見てやって下さい。

ぱっと見ただけの印象ですが....

Linda の本質的な所は「分散共有と同期」だと思うのですが，このプログラム
は replicated server の入口を実装しているだけのように見えます....


# 以下は受け売り．記憶違いがあるかも．しかも受け売り元が元論文じゃない
# し（``Distributed Operating Systems'', Chap. 6, A. S. Tanenbaum.）．

    class TupleSpace
      # 本物はあらゆる tuple（ほぼ直積）に対して任意のパターンでマッチ
      # ングできるけど，めんどうくさいからハッシュ様の形態を仮定する．
      # つまり全てのタプルは [key, val] なる形で，マッチングは第一要素
      # に対するもののみとする．
    
      def get(key)
        # キー key にマッチするタプルを返す．このタプルは TupleSpace
        # から削除される．無かったら待つ．
      end
    
      def put(key, val)
        # [key, val] なるタプルを．登録する．同じキーを持つタプルが複
        # 数存在しても良い．
      end

      # この TupleSpace のインスタンスは全てのノード/プロセス/スレッド
      # から参照できる．ただしアクセスはメソッドのみに限定される．各メ
      # ソッドはアトミックだったような気がする．
    end

と，こんな感じだったはず．

# 本当は TupleSpace#in と TupleSpace#out なんだけどどっちがどっちだっ
# たか忘れた．あと TupleSpace#read（読みだすだけでタプルを削除しない）
# と待たない get（無かったらエラーで帰る）があったような気がする．

val に値そのものでなくて将来値が与えられる place holder（future みたい
な）をいれる事ができる拡張あり．


> Lindaの様にリクエストをtuple spaceに投入するのではなく、
> 手の空いたサービスをプールしておいて、リクエストが投入されると
> その中から一つ取り出して処理をお願いするものです。

で，これは

    # サーバ側
    while
      # req :: ["req", [answer code, request data]]
      req = ts.get("req")
      ac = req[1][0]
      ans = do_process(req)
      ts.put(ac, ans)
    end
    
    # クライアント側
    ts.put("req", [ac, data])
    # ans :: [answer code, answer data]
    ans = ts.get(ac)

こんな風に実現される，と．もちろん ts に TupleSpace のインスタンスを代
入するコードとか，ユニークな answer code の生成とか，その他諸々が必要
になります．

サーバを replicate するばあいでも，単にサーバプロセスを複数立ち上げれ
ば良いのがちょっと嬉しい．

# 茶筅サービスのような場合．複製間の一貫性制御やその他の関係で，実際に
# はそううまくいかないのが分散環境のめんどうさ :-P


Server replication の実装としては別に何の問題もないのですが，``Linda''
を名乗るからには普通のタプルスペースを実装してないとまずいのでは．

# 考えすぎ?


-- 
柳川和久 @ 東大阪市 . 大阪府                              December 28, 1999
What can't be seen is what can't be there.