YamaKen
yamak****@bp*****
2005年 9月 25日 (日) 00:24:46 JST
At Sat, 24 Sep 2005 23:07:54 +0900, tkng****@xem***** wrote: > > On Sat, 24 Sep 2005 14:16:32 +0900 > YamaKen <yamak****@bp*****> wrote: > > r1558のcommit logには"to make uim reentrant"とあり、 > > UIM_EVAL_FSTRINGn_WITH_MUTEX()というmutex付きevalマクロが導入さ > > れています。しかし、uimの中核であるSchemeインタプリタは現在trunk > > で使用されているSIODにしても近く導入予定のSigSchemeにしても > > reentrantではありません。よって、これを変えない限りはuimのC部分 > > がいくらmutex lockの粒度を小さくしても肝心のScheme部分ですぐに待 > > たされる事になり無意味です。 > > libuimの関数は全て短時間で返ることが期待されるので、Thread safeにさえ > なれば、これ以上mutexの粒度を下げても大してメリットは無いと思っていま > す。というわけで、mutexの粒度を下げる予定はありません。というか、これで > うまくいったら、mutex回りはもういじりたくないです。 これ以上lock粒度を下げるつもりがないというのは安心しました。でも 現状でも必要以上に細かすぎるので、もっと粗くAPI関数の入口と出口 だけでlock/unlockを行うようにしましょう。 > > このような事情から現在のuimではAPI関数毎にgiant lockをかけるのが > > 現実的な落としどころだと思いますし、徳永さんの日記でもそういった > > 意図でアドバイスをさせてもらいました。表現が悪くて伝わらなかった > > かもしれませんが。 > > ThreadまわりはAPI関数毎にgiant lockをかける、というのはひとつのmutexを > libuim内部で共有する、という事でいいのでしょうか？そういう仮定で話を進め > ます。 そういう事です。 > この場合、uim_switch_imで問題が出てきます。uim_switch_imは > uim_reset_contextを呼びますが、uim_reset_contextは外部から呼ばれる可能性 > があるので、API毎にロックをかけると、二重でロックしてしまうことになりま > す。 > > これを解決するには > > a. 再帰的なロックを使う > b. staticなuim_reset_context_internalという関数を作り、uim_reset_context > はロックをかけてからuim_reset_context_internalを呼ぶだけの関数にする (snip) > b. は個人的に気に入らないやり方なのでやりません。やるなら全ての関数で > やるべきだと思いますがそれはあまりに手間だし、uim_reset_contextだけ > 別途非ロック版を用意するのは面白くない。 mutexを一つだけにする事と同一スレッドからの再帰ロックを許すかど うかは直交した問題ですよね。とりあえずコードを見てみたいので実装 本体部分のみcommitするかパッチ出すかしてもらえますか? ついでにuim_switch_im()自体もuim-switch-im経由で2重に呼ばれる事 がありますね。 他にuim_get_candidate()もlock中の状態で呼ばれる事になりますが、 こっちはuim_get_candidate()中ではロックを行わずコールバック関数 中でのみ利用を許可する事でロックを無くす事もできます。 > [Anthy-dev 2337] は「単純なポインターの読み書きにロックをかける必要は無 > い」という話で、thread safeにする責任については扱ってないと思うのです > が、 引用がいいかげんすぎました。すいません。以下の意見を指していまし た。 At Fri, 2 Sep 2005 10:56:20 +0900, gniib****@m17n***** wrote: > uim のコードとしては、単にロック無しにするのが良いと思われますけれども。 At Sat, 24 Sep 2005 23:07:54 +0900, tkng****@xem***** wrote: > 「thread safeにする責任をlibuimより上の層に委ねる」というのはどうい > う事でしょうか？Bridge側でロックをかけるようにするとか？ bridgeまたはツールキット、アプリケーションの層でロックをかけると いう事です。immodule機構を持つツールキットでは自動的にそれを行う ような設計になっていてもおかしくはありません。 > それと、pthreadの存在検出だけでは不十分、というのは、どういう場合に問題 > が起こるのでしょう？pthreadが存在する場合はそれをリンクするようにすれば > それで動作上は問題ない（シングルスレッドなアプリケーションでパフォーマン > スが少し無駄に落ちるだけ）ように思えます。 最悪の場合クラッシュします。 pthread-enabledなexecutable/libraryとそうでないものを使い分ける 環境が存在します。そういった環境ではpthread-enabledかどうかでラ イブラリ関数の実シンボル名やcrt(C runtime)、フレームの構造も違っ たりするので、基本的にpthread-enabledなオブジェクトをそうでない ものとリンクする事は避ける必要があります(libcからして2通りあった りします)。 ------------------------------- ヤマケン yamak****@bp*****
