Hatena::Groupcadr

わだばLisperになる このページをアンテナに追加 RSSフィード

2004 | 12 |
2005 | 01 | 02 | 07 | 10 | 11 |
2006 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 11 |

2010-05-27

(19)ELIS Common Lispのマルチプログラミング機能(1989)

| 13:24 | (19)ELIS Common Lispのマルチプログラミング機能(1989) - わだばLisperになる を含むブックマーク はてなブックマーク - (19)ELIS Common Lispのマルチプログラミング機能(1989) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

国産のLISPマシンであるELISでは、TAOが動いていたというのは知られるところだと思うのですが、CLも動いていたというは、CiNiiで論文が読めるようになってから知りました。

ELIS Common Lispは、TAOの機構を継承し、CLと競合するところは、CLを優先、ということなので、TAOのCL版という感じだったのかもしれません。

本文は、ELIS CLのマルチプログラミング機能について述べられていますが、CLでは、マルチプログラミング機能は仕様に定められておらず(当時のCLtL1でも今のANSI CLでも)、拡張部分となります。

特徴としては、単一アドレス空間で、リエントラント性が確保されるような拡張がされていて、

  1. 名前空間は、プロセスごとにCLのパッケージを切る
  2. 同期プリミティブは、言語仕様には含めず、システムが提供するものを利用する
  3. トップレベルの変数もプロセスごとにLETでの束縛のように振る舞う(大域の共有はしない)。
    1. 共有する場合は、defglobalか、defconstant宣言する。defglobalで宣言すると束縛はできず、代入しかできない変数となる
  4. シンボルの属性リストはプロセスごとに異なるようにする。共通にしたい場合は、特別な宣言をする

等が実現方法として述べられています。

ここ1年位で、SBCLにも拡張としてdefglobalが導入されて、その性質も同じく代入しかできないというものですが、他のCL処理系の拡張や、MIT系のLispマシンにもあるようなので、この辺りは定番なのかもしれません。

プロセスごとにごとにパッケージを用意するというのは、自動で行なわれるのか、ユーザーがそういうコーディングをするものなのか詳しく述べられてはいませんが、興味深いです。

ちなみに、SBCLのスレッドでは、

  1. 大域のスペシャル変数は、全スレッドで共有される
  2. (ローカル)束縛のスペシャル変数は、親子スレッドで共有されない
  3. (ローカル)レキシカル変数は、親子スレッドで共有される

となっているようです。最近のCL処理系は大体こういう動きみたいですが、振舞い的にはELIS CLと結構違いますね。

ゲスト



トラックバック - http://cadr.g.hatena.ne.jp/g000001/20100527