5

昨年 5 月にポートランドで開催された Railsconf で、Rails では @@foo のような Ruby クラス メンバー変数は本質的に非スレッドセーフであるため危険であると主張されたプレゼンテーションに参加しました。

後で質問を調査しましたが、質問を実際に具体化するリンクは見つかりませんでした。Rails とスレッドに関する、クラス メンバーの質問に実際に触れている優れた記事へのポインタをいただければ幸いです。また、Rail 2+ と Yarv がこの点に関してどのように変化したかを知っておくとよいでしょう。

編集:

おそらく私のプレゼンテーションの記憶は曖昧ですが、@@foo には、共有変数へのアクセスを厳密に制御する必要があるという通常の注意事項以外の問題があったことを覚えています。少し前に修正された Ruby コード自体にメモリ リークがあったことは知っています。Ruby の共有変数とマルチタスクに関する記事のリンクを探しています。※このため現在はクラス変数を何にも使っていませんが、場合によっては使えたらいいなと思っています。

4

2 に答える 2

5

共有された変更可能な状態は、本質的にスレッドセーフではありません。すべてのアクセスをロックして、すべてが安全であることを確認し、すべてが再入可能であることを確認する必要があります。 @@fooサブクラスが変数にアクセスできるため、コードを監査するのが難しくなるため、特に悪いです。Rails 2+ は、すべてを監査し、必要に応じてミューテックスやその他の同期プリミティブが使用されていることを確認することで、問題を「解決」しました。

于 2009-02-20T02:26:37.520 に答える
1

以前と同じように問題ないと思いますが、クラスが複数回 (たとえば、mongrel を使用している場合は mongrel ごとに 1 回) ロードされる可能性がある Rails 環境では注意して使用する必要があるため、クラス メンバー変数はそれらのプロセス内で独立して変化します。

Ruby 1.9 では @@ 変数のスコープが変更されていると思いますが、これはおそらく考慮に入れる必要があります。

あなたが念頭に置いていた特定の用途はありましたか?私は最近それが必要だと思っていましたが、トピックについての私の (大ざっぱな) 理解の誤りであることが判明しました。私が実際に必要としていたのは、クラスのインスタンス変数でした。(AR スタイルの宣言型マクロの利点を追加できるように、クラスを拡張するモジュールを作成していました。)

于 2009-02-20T12:27:24.893 に答える