From: keiju@... (=?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEI=?=)
Date: 2011-01-25T15:10:38+09:00
Subject: [ruby-dev:43099] Re: pthread_cond を用いたConditionVariable

けいじゅ＠いしつかです.

In [ruby-dev:43098] the message: "[ruby-dev:43098] Re: pthread_cond を
用いたConditionVariable", on Jan/25 12:38(JST) Yusuke ENDOH writes:

>遠藤です。

>現行の CV もコア部分 (Mutex#sleep) は native_sleep の 
>pthread_cond_wait のはずなんですが、何が違うんでしょうね。細々した部
>分がRuby 実装部分で Array とかいじってるのが遅いのかなあ。

たぶんそうだと思います. waitで待っているThreadの数が多くなるほど現行の
CVはパフォーマンスが悪くなります. ただ, 待ちthreadが1000とかのオーダー
だと, 6倍ぐらいのパフォーマンスの低下になります(新CVは1.3倍). ただ, 待
ちthreadが1000 とかは実用上はあまりないと思いますが.

>こういうのは安定させるのが大変そうですね。

そうなんですよね. ですので, もっと良く知っている人の力を借りたいと思っ
たわけです.

>パッチ眺めただけで申し訳ないんですが、
>
>+  BLOCKING_REGION_CORE({
>+      native_mutex_lock(&arg->cv->lock);
>+      th->transition_for_lock = 0;
>+      native_cond_wait(&arg->cv->cond, &arg->cv->lock);
>+      th->transition_for_lock = 1;
>+      native_mutex_unlock(&arg->cv->lock);
>+    });
>
>の部分は、native_mutex_lock の直前に別スレッドで CV#signal が呼ばれたとき、
>signal が無視される気がしました (気のせいかもしれませんが) 。
>
>+  native_mutex_lock(&arg->cv->lock);
>+  BLOCKING_REGION_CORE({
>+      th->transition_for_lock = 0;
>+      native_cond_wait(&arg->cv->cond, &arg->cv->lock);
>+      th->transition_for_lock = 1;
>+    });
>+  native_mutex_unlock(&arg->cv->lock);
>
>とすればいい、のかなあ。

確かにここは気にはなっていたのですが...

thread_pthread.cの

  native_sleep(rb_thread_t *th, struct timeval *tv)

の実装が同じようになっていたので合わせたんですよねぇ... 
こっちのConditionVariableの方に問題あるとすると, native_sleepの方も問
題ある?


__
---------------------------------------------------->> 石塚 圭樹 <<---
---------------------------------->> e-mail: keiju@ishitsuka.com <<---