0

多くの場合、アクティブ オブジェクトのように動作する (スレッドを持つ) クラスがあります。アクセス違反を避けるために、私は常にデストラクタに参加するのを待たなければなりません。これは通常問題ではありません。

ただし、何らかのバグ (デッドロック、ライブロックなど) があるリリース ビルドを想像してみてください。これにより、join()時間どおりに返されないか、まったく返されません。これにより、再度使用されないオブジェクトを待機している間、アプリケーション全体が機能しなくなります。これが顧客で発生すると、問題になります。

私はむしろ問題によって通知され、参加をスキップしたいと思います。そして、スレッドとそのリソースをリークします。

結合のスキップは、このような方法で実現できます。

   class MyActiveObject
    {
    public:
        MyActiveObject();
        ~MyActiveObject(){}
    private
        struct Implementation;
        std::shared_ptr<Implementation> pImpl_;
    };

    struct MyActiveObject::Implementation : std::enable_shared_from_this<Implementation >
    {
        Implementation() : thread_([=]{Run();})
        {
        }

        ~Implementation()
        {
            #ifdef _DEBUG
                thread_.join();
            #else
                if(!thread_.timed_join(SOME_TIMEOUT))
                    ALERT_SOME_HOW();
            #endif
        }

        void Dispose()
        {
            isRunning_ = false;
        }

        void Run()
        {
        #ifndef _DEBUG
            auto pKeepAlive = shared_from_this(); // Won't be destroyed until thread finishes
        #endif   
            isRunning_ = true;
            while(isRunning_)
            {
                 /* ... */
            }
        }

        boost::thread thread_;
        tbb::atomic<bool> isRunning_;
    };

MyActiveObject::MyActiveObject() : pImpl_(new Implementation()){}
MyActiveObject::~MyActiveObject() { pImpl_->Dispose(); }

これは良い考えですか？または、より良い戦略はありますか？

4

3 に答える 3

3

奇妙な質問: 「コードにバグがあると問題が発生します」。はい、そうです。バグを修正します。紙に書き直そうとしないでください。最初のバグが何であるかを知るまではテストできないため、その種の論文では 2 つのバグしか生成されません。

于 2010-09-08T16:51:42.543 に答える
1

可能であれば、サイクルを見つけてデッドロックを打破するために何らかの構造分析を有効にする方がよいでしょう。

破壊時のデッドロックを見逃す可能性がありますが、そのコンテキスト外でデッドロックをキャッチするために適用できる場合もあります。

于 2010-09-08T16:46:35.980 に答える
1

クライアント アプリケーションを作成していて、この破棄シーケンスの後でアプリケーションの有効期間が短い場合は、合理的な実用的なソリューションのように思えます。いくつかのログを追加し、(少なくとも内部テストから) リリース ログを収集することをお勧めします。

サーバー アプリケーションを作成していて、サーバーのシャットダウン中にこの破壊が行われない場合は、サーバーのリソースが頻繁に不足するのは良いことではないため、この動作はお勧めできません。

どちらの場合も、開発チームは既知のデッドロックの問題を最優先で追跡する必要があります。たとえその影響が顧客から隠されていてもです。

于 2010-09-08T16:45:12.843 に答える