今日のゴール
- Lindaモデルが生まれた背景を理解する
- タプルスペースの基本概念を把握する
- 従来の並行プログラミングモデルとの違いを理解する
1980年代、並行プログラミングの課題
1980年代、コンピュータサイエンスの世界は大きな転換点を迎えていました。マルチプロセッサシステムが実用化され始め、複数のプロセスを協調させる「並行プログラミング」が重要なテーマとなっていたのです。
しかし、当時の並行プログラミングには深刻な問題がありました。
セマフォとモニタの限界
セマフォやモニタを使った排他制御は、プログラマに大きな負担を強いました：
- デッドロック: ロックの取得順序を間違えると、プログラムがフリーズ
- 優先度逆転: 低優先度プロセスが高優先度プロセスをブロック
- スケーラビリティ: 分散環境への拡張が困難
メッセージパッシングの課題
メッセージパッシングは、プロセス間の直接通信を前提としていました：
- 密結合: 送信者と受信者が互いを知っている必要がある
- 同期の難しさ: タイミングの調整が複雑
- スケールの問題: プロセス数が増えると通信パターンが爆発的に複雑化
David Gelernterの革命的アイデア
1985年、Yale大学のDavid Gelernter教授は、これらの問題を根本から解決する新しいパラダイムを提唱しました。それが「Linda」です。
Gelernter教授のアイデアは驚くほどシンプルでした：
「プロセス同士が直接通信するのではなく、共有の『場』にデータを置いて、必要な人が取りに来ればいい」
この「場」がタプルスペース（Tuple Space）です。
タプルスペースの比喩
タプルスペースを理解するには、掲示板をイメージするとわかりやすいでしょう。
- 投稿者は誰が見るか知らない: 匿名性
- 閲覧者は誰が投稿したか知らない: 疎結合
- メモは取られるまで残る: 永続性
- パターンで検索できる: 連想メモリ
タプルとは何か
タプルスペースの基本単位は「タプル」です。タプルは、順序付けられた値の組です。
タプルの例:
("task", 42) # 文字列と整数
("worker", "node-1", 3.14) # 文字列、文字列、浮動小数点
("config", "debug", true) # 文字列、文字列、真偽値
各タプルは：
- 型付き: 各要素は特定の型を持つ
- 不変: 一度作成されると変更されない
- 順序付き: 要素の順序が意味を持つ
Nindaでのタプル表現
Nindaでは、タプルは TupleValue のシーケンスとして表現されます：
import ninda
# タプルの作成
let task = toTuple(strVal("task"), intVal(42))
# → ("task", 42)
let worker = toTuple(strVal("worker"), strVal("node-1"), floatVal(3.14))
# → ("worker", "node-1", 3.14)
let config = toTuple(strVal("config"), strVal("debug"), boolVal(true))
# → ("config", "debug", true)
パターンとマッチング
タプルスペースの強力な特徴は、パターンマッチングによる検索です。
パターンは、具体的な値とワイルドカード（何でもマッチ）の組み合わせです：
パターンの例:
("task", ?) # 第1要素が"task"で、第2要素は何でもOK
(?, 42, ?) # 第2要素が42で、他は何でもOK
(?, ?, ?) # 3要素のタプルなら何でもOK
マッチングの動作
タプルスペース:
("task", 1)
("task", 2)
("result", 100)
("config", true)
パターン: ("task", ?)
マッチするタプル:
("task", 1) ← マッチ！
("task", 2) ← マッチ！
("result", 100) ← マッチしない（第1要素が"task"でない）
("config", true) ← マッチしない（第1要素が"task"でない）
Nindaでのパターン表現：
import ninda
# パターンの作成（nilValue()がワイルドカード）
let taskPattern = toPattern(strVal("task"), nilValue())
# → ("task", ?)
let anyThree = toPattern(nilValue(), nilValue(), nilValue())
# → (?, ?, ?)
3つの基本操作
Lindaモデルは、たった3つの操作でタプルスペースを操作します：
1. out（書き込み）
タプルをスペースに追加します。非ブロッキングで即座に完了します。
out("task", 42) → スペースに ("task", 42) が追加される
# Nindaでの書き込み
await ts.writeAsync(toTuple(strVal("task"), intVal(42)))
2. rd（読み取り）
パターンにマッチするタプルを読み取ります（タプルは残る）。マッチするタプルが見つかるまでブロックします。
rd("task", ?x) → xに42が束縛される。タプルはスペースに残る。
# Nindaでの読み取り
let result = await ts.readAsync(toPattern(strVal("task"), nilValue()))
echo result[1].intVal # 42
3. in（取り出し）
パターンにマッチするタプルを取り出します（タプルは削除される）。マッチするタプルが見つかるまでブロックします。
in("task", ?x) → xに42が束縛される。タプルはスペースから削除される。
# Nindaでの取り出し
let taken = await ts.takeAsync(toPattern(strVal("task"), nilValue()))
echo taken[1].intVal # 42
# タプルはスペースから削除されている
従来モデルとの比較
vs メッセージパッシング
| 観点 | メッセージパッシング | タプルスペース |
|---|---|---|
| アドレッシング | 明示的（宛先指定） | 暗黙的（パターン） |
| 結合度 | 密結合 | 疎結合 |
| 永続性 | 消費即削除 | 明示的に取り出すまで残る |
| 検索 | 順序ベース | パターンベース |
vs 共有メモリ
| 観点 | 共有メモリ | タプルスペース |
|---|---|---|
| アクセス | アドレスベース | 連想（パターン）ベース |
| 同期 | 明示的ロック必要 | 暗黙的（操作が原子的） |
| 分散 | 困難 | 自然 |
| 抽象度 | 低い | 高い |
タプルスペースが解決する問題
1. 時間的疎結合
従来:
Producer → Consumer (同時に存在する必要がある)
タプルスペース:
Producer → [Space] → Consumer (時間差があってもOK)
プロデューサーがデータを書き込んだ後、すぐに終了してもOK。コンシューマーは後から来てデータを取得できます。
2. 空間的疎結合
従来:
Process A ←──network──→ Process B (互いのアドレスを知る必要)
タプルスペース:
Process A → [Space] ← Process B (アドレス不要)
プロセスは互いの存在を知らなくても協調できます。
3. 自然なロードバランシング
複数のワーカーが同じパターンでタプルを取りに行くと、自然に負荷分散されます。
なぜ今、タプルスペースなのか
Lindaモデルは1985年に提唱されましたが、現代のソフトウェア開発で再び注目されています：
- マイクロサービス: サービス間の疎結合な通信に最適
- サーバーレス: 一時的なワーカーとの協調に適している
- IoT: 多数のデバイスからのデータ収集に有効
- 機械学習: 分散学習のパラメータサーバーとして
まとめ
今日は、Lindaモデルとタプルスペースの基本概念を学びました：
- タプルスペース: プロセス間通信のための共有「場」
- タプル: 型付き、順序付き、不変の値の組
- パターン: ワイルドカードを含む検索条件
- 3つの操作: out（書き込み）、rd（読み取り）、in（取り出し）
- 疎結合: 時間的にも空間的にも疎結合を実現
実践課題
明日の準備として、以下を考えてみてください：
- あなたが今開発しているシステムで、タプルスペースが使えそうな場面はありますか？
- メッセージキュー（RabbitMQ、Kafka等）との違いは何だと思いますか？
- タプルスペースの欠点はどんなことが考えられますか？