マルチスレッドテスト(依存関係問題)

昨日の変更で一度作成されたライブラリはグローバルに持つようにしたので、キャッシュを読み込むときに問題が起きるようになった。
問題としては(恐らくだが)、スレッドAがライブラリhogeをキャッシュから読み込んでいるときにスレッドBも同じライブラリを読み込むとどうなるかというもの。 現状だとキャッシュの読み込みには特にロックを取得していないので、データ読込→ライブラリ作成→データ復元→インポートという流れの中で問題が起きるのかなぁと(確証ない、状況証拠のみ)。

上記の仮定が正しいとして、解決方法を少し考えてみた。

1. キャッシュ読み込み時に、プロセスリストを作成し、そのリストの中に自分が必要としているキャッシュがあれば待つ。

   でもこの場合同じライブラリだけど別ファイルだったらどうなるんだ？

2. キャッシュ読み込み自体にロックをかけて、ライブラリが存在しているか確認、あれば帰る

1の場合は同一ライブラリ別ファイルの対処が多分不可能。2の場合はせっかくマルチに走らせるのにキャッシュの読み込みがボトルネックになる。実装としては2の方が楽。
マルチスレッドでloadを使うなんて事がそうあるとは思えないので、とりあえず2を実装してみればいいだろうか？

とりあえず2の方法で上手くいっている。 依存関係問題はマルチスレッド関係なくまだまだあるので、いずれ直さないとなぁと思いつつ。
現状でマルチにテストを走らせる際のポイント。

1. 子スレッドからはcond-featureが追加できないので、ffiはマルチでは走らせられない。

   これはコンパイル結果を親子ともに一緒にする必要があるので。現状ではffi以外はcond-featureを足さないのでとりあえずはOKかと。これが理由でextのテストはマルチでは走らせられない。

2. 子スレッド内では可能な限りライブラリの参照をフルネームで書くこと。

   問題になるのはSRFI-64と自前で作ったR7RSのテストフレームワークの名前競合。ライブラリの参照の問題なんだけど、基本的に後からインポートした方が上書きするのだが、フルネームじゃないと微妙なことが起きる。直す必要があるんだけど、現状では放置

とりあえずテストの実行がかなり速くなったかなぁと。とは言っても、一番の問題だったのはssaxのテストで使われていたsyntax-rules実装のrun-testマクロだったのだが。こいつの展開があほかと思うほど時間かかってた。