2

メンバー std::thread を内部的に保持する Task という名前のクラスがあります。一般的な考え方は、処理の要求が来ても生き続けるスレッドを作成することです。

class Task
{
public:
    Task();
    ~Task();

    void start();
    // some funny stuff here
protected:
    Task(const Task& ref);
    void main_function();

    std::thread m_thread;
    // more funny stuff like queues, mutexes, etc
}

関数 start() では、次のことを行います。

void Task::start()
{
    m_thread = std::thread(std::bind(&Task::main_function, this));
}

問題は、この行がランタイム エラー R6010 で abort() を呼び出すことです。これは、以前の結合なしで呼び出された m_thread のデストラクタが原因である可能性があることをどこかで読みましたが、スレッドがまだ開始されていないため、結合できません。

これをVisual Studio 2012で実行しています

アップデート：

そのため、テスト例を試してみましたが、エラーを再現できませんでした。次に、問題のある関数の開始関数を次のように置き換えました。

void Task::start()
{
    assert(!m_thread.joinable());
    m_thread = std::thread(&Task::main_function,this);
}

しかし、それでもエラー R6010 が表示されます。コール スタックは次のとおりです。

msvcr110d.dll!_NMSG_WRITE(int rterrnum) Line 226    C
msvcr110d.dll!abort() Line 62   C
msvcr110d.dll!terminate() Line 97   C++
msvcp110d.dll!_Call_func(void * _Data) Line 63  C++

msvcr110d.dll!_callthreadstartex() Line 354 C
msvcr110d.dll!_threadstartex(void * ptd) Line 337   C

UPDATE2: 最後に問題を再現できました。コードは次のとおりです。メイン関数で foo() を呼び出します。

class Task 
{
public:
    Task() : m_exitFlag(false) 
    { 
        std::cout << "constructor called" << std::endl;
    }

    ~Task()
    {
        m_lock.lock();
        m_exitFlag = true;
        m_condlock.notify_all();
        m_lock.unlock();

        if (m_thread.joinable()) m_thread.join();
        std::cout << "destructor called" << std::endl;
     }

     void start()
     {
         std::cout << "Task start" << std::endl;
         assert(!m_thread.joinable());
         m_thread = std::thread(&Task::main_function, this);
     }
protected:
     void main_function()
     {
         std::cout << "thread started" << std::endl;
         while(1)
         {
             m_lock.lock();
             while(m_queue.empty() && !m_exitFlag)
                 m_condlock.wait(std::unique_lock<std::mutex>(m_lock));

             if (m_exitFlag)
             {
                 m_lock.unlock();
                 std::cout << "thread exiting" << std::endl;
                 return;
             }

             std::function<void()> f;
             if (!m_queue.empty()) f = m_queue.front();

             m_lock.unlock;
             if (f != nullptr) f();
         }
     }
     Task(const Task&ref) { }

     Task& operator=(const Task& ref) {
         return *this;
     }
};
void foo() {
    Task tk;
    tk.start();
}

クラッシュする場合とそうでない場合があるため、ここのどこかに競合状態があると思います。1 つのスレッドは ~Task() のクリティカル領域内にあり、もう 1 つのスレッドは Update1 のスタックとして存在します。

4

2 に答える 2

1

ミューテックスを直接ロックしないでください。C++ オファーlock_guardなどunique_lock。理由があります。

特に、このセクションは問題があります。

m_lock.lock();
while(m_queue.empty() && !m_exitFlag)
    m_condlock.wait(std::unique_lock<std::mutex>(m_lock));

新しく構築unique_lockされた は、すでにロックされているミューテックスをロックしようとしますm_lock。これにより、mutex が の場合は未定義の動作が発生std::mutexし、mutex が の場合はデッドロックが発生する可能性がありstd::recursive_mutexます。また、 を呼び出すときに無名unique_lock を非constwait参照にバインドするため、この行は非標準のコンパイラ拡張機能に依存していることにも注意してください。

したがって、最初に行う必要があるのは、ロックを名前付き変数にすることです。次に、ロックのコンストラクターに a を渡すかstd::adopt_lock、できればミューテックスを直接ロックせず、常に適切なロック管理クラスでラップします。

例えば、

m_lock.lock();
m_exitFlag = true;
m_condlock.notify_all();
m_lock.unlock();

になる

{
    std::lock_guard<std::mutex> lk(m_lock);
    m_exitFlag = true;
    m_condlock.notify_all();
} // mutex is unlocked automatically as the lock_guard goes out of scope

これには、クリティカル セクション内で例外がスローされた場合にロックがリークしないという追加の利点があります。

于 2014-01-29T16:04:52.977 に答える