15

この有名なスレッド以来、Rubyコミュニティは自動ロードについて少しおかしくなっていて、スレッドセーフの理由からその使用を思いとどまらせているようです。

これがRuby1.9.1または1.9.2で問題ではなくなったかどうか誰かが知っていますか？ミューテックスなどで必要なラッピングについて少し話をしましたが、1.9の変更ログ（または少なくとも私が見つけた限り）はこの特定の質問に対処していないようです。1.9のみのライブラリで、合理的な苦痛なしに自動ロードを合理的に開始できるかどうかを知りたいです。

洞察を事前に感謝します。

4

3 に答える 3

9

私も興味があったので、2011年のアップデートをこれに持ってきてください。

現在、2つのチケットが開かれています。

コア開発者は、CRuby / JRuby 1.9で、requireとautoloadが同じように機能し、スレッドセーフであることを示唆しています。これは、ファイルが完全にロードされるまでrubyがロックを維持するという意味です。

ただし、これには潜在的なデッドロックが発生するという不便な副作用があります。具体的には：

  1. Th1はAをロードしてロックします
  2. Th2はBをロードし、それをロックします
  3. Th1はAのロードの一部としてBをロードしようとし、Th2の待機を開始します
  4. Th2はBのロードの一部としてAをロードしようとし、Th1の待機を開始します
  5. デッドロック...

結論はおそらく次のとおりです。アプリでデッドロックが発生する可能性がある場合は、スレッドを開始する前に必要なものをすべて要求してください。

于 2011-07-02T03:54:37.100 に答える
7

一般的なケースについてはわかりませんが、そのスレッドの再現例は1.9.1では壊れません。

autoloaded.rb：

sleep 1
Bar::Foo = 1

autoloader.rb：

module Bar
   autoload :Foo, 'autoloaded.rb'
end

t1 = Thread.new { Bar::Foo }
t2 = Thread.new { Bar::Foo }
t1.join; t2.join
于 2010-05-14T22:19:06.220 に答える
-4

それは常に壊れています。

サブロードを使用すると、スレッド環境でモードを切り替えることができます。

スレッド環境でオートロードを使用していますが、シングルスレッドのブートシーケンス中のみです。実際のアプリケーションでマルチスレッドの起動プロセスを使用する正当な理由はわかりません。持っている場合は、共有ライブラリをロードするためのアクションをキューに入れる必要があります。これは、クラスおよびインスタンスレベルのセットアップで、特に次のようなスレッドセーフの問題が常に発生するためです。

class Lib
  extend SomeClassFuncs
  do_something_with_class_funcs
end

このコードは、ローダーに関係なく、ロード時にスレッドセーフではありません。

これが表示されない場合は、スレッド化するべきではありません。

于 2010-06-14T11:02:48.847 に答える