問題タブ [stdthread]

これは例です:

出力は次のとおりです。

-O2フラグの有無にかかわらず、gcc 4.5.2 でコンパイルされています。

これは予想される動作ですか？

このプログラムのデータ競合はありませんか?

ありがとうございました

aがまだ実行されているかどうかを確認するにはどうすればよいstd::threadですか (プラットフォームに依存しない方法で)? メソッドがなく、そのためのものtimed_join()でjoinable()はありません。

std::lock_guardスレッド内で a を使用してミューテックスをロックし、ミューテックスのtry_lock()メソッドを使用して、まだロックされている (スレッドが実行されている) かどうかを判断することを考えましたが、不必要に複雑に思えます。

もっとエレガントな方法を知っていますか？

更新:明確にするために:スレッドが正常に終了したかどうかを確認したい。「ハングしている」スレッドは、この目的のために実行されていると見なされます。

Linux は私にとって新しいプラットフォームです。私は何年もの間、Windows で c++ を使用してコーディングしており、そのプラットフォームでのマルチスレッドに慣れてきました。

Linux プラットフォームで C++ を学ぶ必要がある時期に、C++11 が登場しました。

Linux はほとんどの部分で pthreads を使用しているようです。boost::threads もあり、QT にも独自のスレッドがあります。しかし、C++11 には、スレッドを実行するためのまったく新しい (クロス プラットフォームおよび C++ 標準) 方法である std::thread が付属しています。

だから私は pthreads と std::threads を学ばなければならないと思います。最終的には、std::thread の方が重要に思えますが、そこには多くのレガシー コードがあるため、両方を知る必要があります。

Windows でのスレッド同期の場合、WaitForMultipleObjectsを使用して、いくつかのタスクが完了するのを待ってから、さらに作業を続けます。

pthread にも同様の同期メカニズムはありますか? std::スレッド?

私はpthread_joinを見てきましたが、一度に 1 つのスレッドだけを待機する機能があるようです。別の pthread 呼び出しが欠落している可能性がありますか?

次の例は、Ubuntu12.04でClang3.2またはGCC4.7を使用してコンパイルすると正常に実行されます（つまり、ハングしません）が、VS11BetaまたはVS2012RCを使用してコンパイルするとハングします。

問題std::thread::join()は、終了後に呼び出された場合に戻らないということのようmainです。cthread.cWaitForSingleObjectで定義されているでブロックされます。_Thrd_join

SleepFor(100);の最後でコメントを外すと、非静的mainにするのと同様に、プログラムを適切に終了できます。std_testを使用boost::threadすると、問題も回避できます。

それで、ここで未定義の動作を呼び出しているのか（私にはありそうもないようです）、またはVS2012に対してバグを報告する必要があるのか​​どうかを知りたいですか？

私はマルチスレッド アプリケーション (std::thread を使用) とマネージャー (クラス ツリー) を使用して、異なるサブツリー (組み込み構造体サブツリー) でコードの一部を並列に実行しています。基本的な考え方は、SubTree の各インスタンスにはオブジェクトを格納する両端キューがあるということです。両端キューが空の場合、スレッドは新しい要素が両端キューに挿入されるか、終了基準に達するまで待機します。1 つのサブツリーでオブジェクトを生成し、それらを別のサブツリーの両端キューにプッシュできます。便宜上、すべての std::mutex、std::locks、および std::variable_condition は「locks」と呼ばれる構造体に格納されます。

クラス Tree は、次のメソッドを実行するいくつかのスレッドを作成します (最初の試行) :

問題は、スレッドが待機している間、「deque_lock」がまだロックされていることです。したがって、並行スレッドによって現在のスレッドの両端キューにオブジェクトを追加することはできません。

そこで、lock_guard を unique_lock に変更し、手動でロック/ロック解除を管理しました。

ここでの問題は、データ競合があることです。「待機」命令が「deque_lock.unlock()」命令の直後に実行されるようにしたいと思います。標準ライブラリでこのような重要な命令シーケンスを作成する方法を知っている人はいますか?

前もって感謝します。

C++ クラス内にスレッドを埋め込む必要がありますが、アクティブ オブジェクトの一種ですが、厳密にはそうではありません。私はクラスのコンストラクターからスレッドを生成しています。この方法で問題はありますか?

イベントからループを開始し、別のイベントからループを停止する必要があります。私の考えは、ボタンを押したときに関数 startDequeuing() を呼び出してループを開始し、関数 stopDequeuing() から "dequeuing" 変数を false にしてこのループを終了することでした。

スレッドを使用するのは初めてです。変数「デキュー」がロックされており、スレッドの外部からアクセスできないため、ループを開始するとプログラムがロックされます。正しいですか?

どうすればこの問題を解決できますか??

ここにいくつかのコードがあります：

この問題が発生しました-タイトルで..

私はこのコードを持っています:

ウェブからどこかから取得しました。コンパイラ オプション -pthread -std=gnu++0x (-std=c++0x も試しました) と segfault があります。すべてが vmBox の Debian にあります。以前に他のコードを起動しましたが、それらは機能しました。突然、すべての動作中のアプリで std::thread を使用してスレッドに segfault が発生しました。

編集:これはgdbからのものです:

(より高度なアプリを std::thread t(&ClassName::my_thread_func,ptr) で起動すると、エラーは同じですが、他の行 [thread:133])

ウェブで検索しましたが、適切なものが見つかりませんでした。

私はこのようなことをしたい：

ただし、コンパイルされません。http://accu.org/index.php/journals/1584を調べてみましたが、メンバー関数がnew-edオブジェクトにある場合については触れられていませんでした。正しい構文は何ですか？

この質問は、前の質問と非常によく似ています。pthread_once（）の競合状態？

これは本質的に同じ問題です-std::promise呼び出し中の終了 の存続期間promise::set_value（つまり、関連する未来にフラグが立てられた後、pthread_once実行される前）

ですから、私の使用法にはこの問題があることを知っているので、このように使用することはできません。しかし、これは自明ではないと思います。（Scott Meyerの賢明な言葉で：インターフェースを正しく使いやすく、正しく使いにくいようにする）

以下に例を示します。

• dispatcherキューでスピンし、「ジョブ」（a）をポップして実行するスレッド（ ）がありますstd::function。
• synchronous_jobディスパッチャスレッドで「ジョブ」が実行されるまで呼び出しスレッドをブロックするユーティリティクラスがあります
• std::promiseおよびは-のstd::futureメンバーです。が設定されると、ブロックされた呼び出しスレッドが続行され、スタックがポップオフされて破棄されます。synchronous_jobfuturesynchronous_job
• 残念ながら、この時点では、内部dispatcherでコンテキストが切り替えられました。にフラグが立てられていますが、への呼び出しが実行されておらず、pthreadスタックが何らかの理由で破損しています。つまり、次回はデッドロックになります。 promise::set_valuefuturepthread_once

呼び出しはpromise::set_valueアトミックであると思います。フラグを立てた後にさらに作業を行う必要があるという事実は、futureこれらのクラスをこのように使用する場合、必然的にこの種の問題につながります。

だから私の質問は：この同期メカニズムを提供するクラスに関連付けられたライフタイムを維持しながら、std::promiseとを使用してこの種の同期を実現するにはどうすればよいですか？std::future

@Jonathan Wakely、おそらく内部でRAIIスタイルのクラスを使用してcondition_variable、フラグを立てた後にデストラクタにを設定できますfutureか？これはpromise、への呼び出しの途中でが破棄された場合でもset_value、条件変数を設定する追加の作業が正しく完了することを意味します。ただのアイデア、それを使用できるかどうかわからない...

以下の完全に機能する例と、その後のデッドロックされたアプリのスタックトレース：

デッドロックされたアプリのスタックトレース：

スレッド1（メインスレッド）

スレッド2（ディスパッチャースレッド）