ささだです。

Yukihiro Matsumoto wrote:
> In message "Re: [yarv-dev:631] Re: thread support"
>     on Fri, 30 Sep 2005 22:10:41 +0900, SASADA Koichi <ko1 atdot.net> writes:
> 
> |　たとえば、String オブジェクトの RSTRING(str)->ptr のような操作は排他制
> |御が必要になる（これを全部排除しようとすると大変...）。これは、例えば
> |ptr を取得したあと、スレッドスイッチが起こり、他のスレッドが str に対し
> |て破壊的操作をして、ptr が指しているメモリオブジェクトを REALLOC なりし
> |た場合、元のスレッドが free したメモリオブジェクトを参照してしまいます。
> |
> |ThreadA
> |  ptr = RSTRING(str)->ptr;
> |ThreadB (switch)
> |  RSTRING(str)->ptr = other_memory_location;
> |ThreadA (switch)
> |  ptr[0]; /* error! */
> |
> |　そのようなことが起こらないように、細かく排他制御を行わなければならな
> |い。（排他制御を行わないが高速な実装を提供し、Ruby ユーザの責任、とする
> |ことも出来るが、処理系として正しいかは謎）。
> 
> この件に関しては、Gaucheみたいにreallocやfreeを行わないのも
> ひとつの考えかもしれません。もっともそれだとBoehm GCかその同
> 等品を必要とすることになるわけですが。

　すみません、Gauche って relloc や free をしないんでしたっけ？

　ちなみに、realloc や free をしない実装にするとして、たとえば len （文
字列の長さ）と ptr （文字列の実体）で一貫性が取れなくなって危険なケース
がありそうな気がするんですが、そうでもないんでしょうか。もちろん、処理系
のプログラマが気をつければいい話ではありますが。

　すべてのスレッドが安全な位置で同期をすることを保証すれば、GC 時に一気
に free、という実装（Boehm GC みたいなことを処理系でやる）もありそうだ
な、と思ったのですが、上記の一貫性の不一致の点に思い当たりました。


> |　また、今後の開発方針などに対してご意見などあればご教示ください。
> 
> 私はm1でも平気ですが、世の中の要求はnative threadになんらか
> の形で対応してほしいということのようです。
> 
> 当面m2で、段階的に(たとえばVMはスレッドセーフにしてGIを開放
> するが、C関数実行中はGIを使う、とか)m3に近づければ良いのでは
> ないでしょうか。

　段階的な、という話は思い至りませんでした。その線で開発してみようと思い
ます。スレッドセーフな関数（例えば Numeric 関係）は rb_define_func にオ
プションを渡せるようにするといいのかも（ロックが必要かどうか判断するフラ
グ）。


> |　この辺のニーズの把握って、たとえば NaCl さんなんかでは何かデータあった
> |りしますか。
> 
> うちでthreadを積極的に使った例はありません。

　誰か、スレッドをばしばし使いそうな人居ませんかねぇ。


-- 
SASADA Koichi at atdot dot net

--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml