2

私は C++ boost::thread ライブラリを使用しています。これは、私の場合は pthreads を使用していることを意味します。公式には、ミューテックスはそれをロックしている同じスレッドからロック解除する必要があり、あるスレッドでロックしてから別のスレッドでロック解除できるという効果が必要です。これを実現するには多くの方法があります。1 つの可能性は、この動作を許可する新しいミューテックス クラスを作成することです。

例えば：

class inter_thread_mutex{
  bool locked;
  boost::mutex mx;
  boost::condition_variable cv;
public:
  void lock(){
    boost::unique_lock<boost::mutex> lck(mx);
    while(locked) cv.wait(lck);
    locked=true;
  }

  void unlock(){
    {
      boost::lock_guard<boost::mutex> lck(mx);
      if(!locked) error();
      locked=false;
    }
    cv.notify_one();
  }
// bool try_lock(); void error(); etc.
}

あるスレッドが lock() を呼び出し、別のスレッドが unlock() を呼び出した場合、この最初のスレッドが、待機している他のスレッドより先にロックを取得する可能性があるため、上記のコードは FIFO アクセスを保証しないことを指摘しておく必要があります。(考えてみると、boost::thread のドキュメントでは、ミューテックスまたは条件変数のいずれに対しても明示的なスケジューリング保証が行われていないようです)。しかし、今はそれ (およびその他のバグ) を無視しましょう。

私の質問は、もし私がこの道を進むことにした場合、そのようなミューテックスをブースト ロック可能コンセプトのモデルとして使用できるかどうかです。 boost::unique_lock< inter_thread_mutex > たとえば、 RAII スタイルのアクセスに を使用し、このロックをboost::condition_variable_any.wait()などに渡すと、何か問題が発生します。

一方では、なぜそうしないのかわかりません。一方、「なぜだかわからない」というのは、通常、何かがうまくいくかどうかを判断するための非常に悪い方法です。

私が尋ねる理由は、RAII ロックや条件変数などのラッパー クラスを作成する必要があることが判明した場合は、同じ効果を達成するための別の方法を見つけたいからです。

編集:私が望む動作の種類は、基本的に次のとおりです。オブジェクトがあり、変更するたびにロックする必要があります。オブジェクトを 1 つのスレッドからロックし、そのオブジェクトに対して何らかの作業を行いたいと考えています。次に、別のワーカー スレッドに作業を完了するように指示している間、オブジェクトをロックしたままにします。そのため、ワーカー スレッドが終了している間に、最初のスレッドが続行して別の処理を行うことができます。ワーカー スレッドが完了すると、mutex のロックが解除されます。

そして、スレッド 1 が作業を開始してからスレッド 2 が作業を完了するまでの間、他の誰もミューテックス ロックを取得できないように、トランジションをスムーズにしたいと考えています。

inter_thread_mutex のようなものは機能するように見え、プログラムは通常のミューテックスであるかのように対話することもできます。だから、それはきれいな解決策のようです。より良い解決策があれば、それも聞いてうれしいです。

もう一度編集: 最初にロックが必要な理由は、複数のマスター スレッドがあり、共有オブジェクトに無効な方法で同時にアクセスするのを防ぐためにロックが存在するためです。そのため、コードはマスター スレッド レベルでループ レベルのロックのない操作の順序付けを既に使用しています。また、元の実装では、ワーカー スレッドはなく、ミューテックスは通常のコーシャ ミューテックスでした。

inter_thread_thingy は、主に応答時間を改善するための最適化として登場しました。多くの場合、操作 A の「最初の部分」が操作 B の「最初の部分」の前に発生することを保証するのに十分でした。馬鹿げた例として、オブジェクト 1 をパンチして目を黒くしたとします。次に、オブジェクト 1 の内部構造を変更して、すべての組織損傷を反映するように指示します。オブジェクト 2 のパンチに移る前に、組織の損傷を待ちたくありません。ただし、同じ操作の一部として組織の損傷を発生させたいと考えています。たとえば、当面の間、組織の損傷を無効な操作にするような方法で、他のスレッドがオブジェクトを再構成することは望ましくありません。(はい、この例は多くの点で不完全です。いいえ、私はゲームに取り組んでいません)

そのため、オブジェクトの所有権をワーカー スレッドに渡して操作を完了することができるモデルに変更を加えましたが、実際には非常にうまく機能します。すべての操作が完了するのを待つ必要がないため、各マスター スレッドはより多くの操作を実行できます。また、マスター スレッド レベルでのイベント シーケンスは依然としてループベースであるため、高度なマスター スレッド操作を簡単に記述できます。これは、操作が完了したという前提に基づくことができるためです (より正確には、重要な "対応する関数呼び出しが返されたときに、シーケンス ロジックが依存する最初の部分" が完了します。

最後に、すべてを機能させるために必要な同期をカプセル化するために、RAII とブースト ロックを使用して inter_thread ミューテックス/セマフォを使用するとよいと思いました。

4

6 に答える 6

3

man pthread_unlock(これは OS X で、 Linuxでの同様の文言) には答えがあります:

名前
     pthread_mutex_unlock -- ミューテックスのロックを解除する

あらすじ
     #include <pthread.h>

     整数
     pthread_mutex_unlock(pthread_mutex_t *mutex);

説明
     現在のスレッドがミューテックスのロックを保持している場合、
     pthread_mutex_unlock() 関数はミューテックスのロックを解除します。

     そのミューテックスで pthread_mutex_unlock() を呼び出すと、
     呼び出しスレッドが保持されないと、
     未定義の動作。

     ...

私の反対の質問は、これでどのような同期の問題を解決しようとしているのかということです。おそらく、もっと簡単な解決策があります。

競合するミューテックスが競合するスレッドによって取得される順序は保証されませpthreadsん。boost::thread

于 2010-05-02T20:54:19.343 に答える
0

あなたがすでに持っているものへの小さな変更：あなたがあなたの中に、あなたがロックしたいinter_thread_whateverスレッドのIDを保存するのはどうですか？次に、ロックを解除し、そのスレッドに「このロックを取得しようとするルーチンを実行してほしい」というメッセージを送信します。

すると、の条件はにlockなりwhile(locked || (desired_locker != thisthread && desired_locker != 0))ます。技術的には、最初のスレッドで「ロックを解除」し、2番目のスレッドで「再度取得」しましたが、他のスレッドがその間にロックを取得する方法がないため、から直接転送したかのようになります。一方から他方へ。

潜在的な問題があります。スレッドが終了または強制終了された場合、それがロックの目的のロッカーであるときに、そのスレッドがデッドロックします。しかし、あなたはすでに2番目のスレッドからのメッセージを待っている最初のスレッドがロックを正常に取得したことを話していたので、おそらくそのメッセージが受信されなかった場合に何が起こるかについてすでに計画を立てています。その計画に、「inter_thread_whateverのdesired_lockerフィールドをリセットする」を追加します。

これはすべて非常に毛深いですが、私が提案したことが正しいとは確信していません。「マスター」スレッド（これらすべてのヘルパーを指示するスレッド）が、最初の操作が完了するまで、このロックによって保護されているものに対して実行される操作をこれ以上命令しないようにする方法はありますか（または失敗し、いくつかのRAIIが通知します）？メッセージループのレベルでロックを処理できる場合は、ロック自体は必要ありません。

于 2010-05-03T12:34:28.597 に答える
0

inter_thread_mutexあなたの(binary_semaphore) を Lockable のモデルと見なすことができると言うのは良い考えではないと思います。主な問題は、あなたの主な機能がコンセプトinter_thread_mutexを打ち負かすことです。Locakbleロック可能なモデルであった場合inter_thread_mutex、[1] で inter_thread_mutex m がロックされていることが予想されます。

// thread T1
inter_thread_mutex m;

{
  unique_lock<inter_thread_mutex> lk(m);
  // [1]
}

しかし、T1 が [1] にある間に別のスレッド T2 が実行できるようm.unlock()に、保証は破られます。

Lockablesバイナリ セマフォは、各スレッドがロックを解除する前にロックを試行する限り使用できます。しかし、あなたのクラスの主な目標は正反対です。

これが、Boost.Interprocess のセマフォがロック/ロック解除を使用して関数に名前を付けず、待機/通知する理由の 1 つです。不思議なことに、これらは条件で使用される名前と同じです:)

于 2010-05-04T08:53:46.630 に答える
0

申し訳ありませんが、わかりません。別のスレッドがロックを解除できる場合、次のコードの行 [1] のミューテックスの状態はどうなりますか?

inter_thread_mutex m;

{
  m.lock();
  // [1]
  m.unlock();
}

これにはセンスがありません。

于 2010-05-02T21:30:16.967 に答える
0

これにアプローチするにはいくつかの方法があります。私が提案しようとしているものはどちらも、それを所有しているスレッド以外のスレッドからスレッドのロックを解除するメカニズムを追加するのではなく、オブジェクトに追加の情報を追加することを伴います。

1) オブジェクトの状態を示す情報を追加できます。

enum modification_state { consistent, // ready to be examined or to start being modified
                          phase1_complete, // ready for the second thread to finish the work
                        };

// first worker thread
lock();
do_init_work(object);
object.mod_state = phase1_complete;
unlock();
signal();
do_other_stuff();

// second worker thread
lock()
while( object.mod_state != phase1_complete )
  wait()
do_final_work(obj)
object.mod_state = consistent;
unlock()
signal()

// some other thread that needs to read the data
lock()
while( object.mod_state != consistent )
  wait();
read_data(obj)
unlock()

明らかに独自のロックを作成していないため、条件変数で問題なく動作します。

2) 特定のスレッドを念頭に置いている場合は、オブジェクトに所有者を与えることができます。

  // first worker
  lock();
  while( obj.owner != this_thread() ) wait();
  do_initial_work(obj);
  obj.owner = second_thread_id;
  unlock()
  signal()

  ...

これは私の最初のソリューションとほぼ同じソリューションですが、フェーズの追加/削除の柔軟性が高く、スレッドの追加/削除の柔軟性が低くなります。

正直なところ、ここでスレッド間ミューテックスがどのように役立つかわかりません。作業を 2 番目のスレッドに渡すことを通知するために、セマフォまたは条件変数が必要です。

于 2010-05-02T22:17:07.270 に答える
-1

ミューテックスは、相互に排他的なコード ブロックを記述するためのメカニズムです。これらのコード ブロックがスレッドの境界を越えることは意味がありません。このような概念を直観に反する方法で使用しようとすると、問題が発生するだけです。

別のマルチスレッドの概念を探しているように聞こえますが、詳細がわからないと何が何なのかわかりません。

于 2010-05-02T21:36:59.850 に答える