2

ブースト固有のロックオブジェクトがインスタンス化できるのはスタック上でのみで、ヒープ上ではインスタンス化できない理由を誰かが知っていますか？

これは完全に機能します：

boost::unique_lock<boost::mutex> lock1(mutex1);
:
wait_condition.wait(lock1);

ただし、これにより、mingwでコンパイルした後、Windows7とWindows8の両方でランタイムクラッシュが発生します。

boost::unique_lock *lock1;
lock1 = new boost::unique_lock<boost::mutex>(mutex1);
:
wait_condition.wait(*lock1);

前もって感謝します

4

1 に答える 1

0

Igor さん、ご回答ありがとうございます。ブースト 1.52.0 を使用しています。RAII ステートメントは私に考えさせましたが、以前に認識すべきだったことに気付きました: ヒープ上に作成すると、unique_lock が作成された関数を終了した後でも、ロックが範囲外に出ることはありません。待機が戻ると、関数が戻るときにヒープベースのロックを解除せずに再度ロックするため、デッドロックが発生します。このコンテキストでのクラッシュとは、「アプリケーションがフリーズして閉じられない」という意味です。

上記の問題は解決しました。ただし、新しい問題が発生しました :-) RAII パラダイムに従ってスタックを使用した後でも、25 個の子スレッドが待機状態になるとアプリケーションがクラッシュします。どうしてか分かりません。25 を超えるスレッドがミューテックスで待機している Windows、ブースト、または mingw の制限はありますか? 25 スレッドを超えるクラッシュは、上記よりも深刻です。Windows エラーで適切にクラッシュします:「アプリケーションは予期しない方法で強制終了されました」。これは、25 未満のスレッドでは発生しません...

于 2013-02-16T22:51:59.977 に答える