クラス: wxThread, wxMutex, wxCriticalSection, wxCondition
wxWidgets はマルチスレッド (MT) プログラムで必要となるオブジェクトをカプセル化したクラスの一式を提供しています: thread クラス自身と、他の同期オブジェクトである ミューテックス、クリティカルセクション、コンディション が含まれます。いくつかの関数の名前が異なりますし、Win32 スレッド API にインスピレーションを受けた機能もありますが、wxWidgets のスレッド API は (pthread としても知られる) POSIX1.c のスレッド API によく似ています。
これらのクラスによって、おそらくマルチスレッドプログラムの作成がより簡単になる上に、(ネイティブ (Win32 または Posix) スレッド API と比較して) いくつかの追加エラーチェックを行なってくれます。ただし、依然としてこれは簡単な仕事ではありませんし、巨大プロジェクトでは特にそうだと思います。マルチスレッドアプリケーションの開発を始める前に (もしくは既存のアプリケーションにマルチスレッド機能を追加する前に)、同じ機能を実装するためのより簡単で安全な方法がないか自問するだけの価値はあります。もちろん、いくつかの状況ではスレッドは本当に意味がありますが (古典的な例ではサーバアプリケーションでクライアントごとに新しいスレッドを実行することが挙げられます)、それ以外の場合ではお粗末な選択になるでしょう。(例: 長い計算をするときにプログレスダイアログを表示するために別のスレッドを実行する) 他の実装方法を選択することは可能です: プログレスダイアログの例で言うと、アイドルハンドラ で計算を行なうか、もしくは単純に一度に計算を行い、画面を更新するために定期的に wxWindow::Update() を呼び出す方がずっと良い方法です。
アプリケーションでスレッドを使用すると決めた場合、複数のスレッドで GUI 関数を呼び出さないことを強く推奨します。スレッドのサンプルは GUI 関数を同時に異なるスレッドから呼び出すことが 可能 なことを示していますが (サンプル中のすべてのスレッドから GUI にアクセスしています)、サンプル以外のデザインの選択肢はほとんどありません。ひとつの GUI スレッドと複数のワーカースレッドを使用し、イベントを使用してメインスレッドと通信するデザインはよりロバストで、無数の問題が起こるのを間違いなく防いでくれます。(例: Win32 では自スレッドで作成した GDI オブジェクト (ペンやブラシなど) にだけアクセスでき、他スレッドで作成したオブジェクトにはアクセスできません)
メインスレッドとサブスレッドとの通信には wxEvtHandler::AddPendingEvent か、もしくはその短縮版である wxPostEvent を使用します。これらの関数はスレッドセーフに実装されているため、あるスレッドから他のスレッドへイベントを送信するのに使用できます。しかし、ワーカースレッドへメッセージを送信するためのビルトイン関数は存在しないため、要件にあった解決方法を実装するために既存の同期オブジェクトを使用する必要があります。特に、メッセージを送信するために wxThread クラスと wxEvtHandler を継承するだけでは 不十分 なことに注意してください: 実際のところ、これはまったく動作 しません。