2016-08-29 1 views
1

状況:mutexの所有権は、ロック解除の前にロックを要求したスレッドにのみ厳密に渡されますか?

  1. スレッド1は現在、ミューテックスを所有しています。
  2. スレッド1はmutexの所有権を保持しますが、スレッド2は同じロックを要求します。
  3. スレッド1はロックを解除します。

この時点で、別のスレッド(スレッド3など)がロックを要求して取得することができます(下記参照)。あるいは、POSIXは、mutexのロックを解除する瞬間に、すでにそのmutexを待っているスレッドがmutexを取得することを保証していますか?

MUTEX_acquisition_race

pthread_mutex_unlock()状態のマニュアルページ -

pthread_mutex_unlockの()が使用可能 なってミューテックス、その結果、呼び出されたときに、ミューテックス によって参照ミューテックスオブジェクトでブロックされたスレッドが存在する場合スケジューリング方針は、どのスレッドがmutexを獲得するかを決定するものとする。

これは、私が完全に保証されていないにもかかわらず、スレッド3が襲撃されてミューテックスを得ることができないと言います。

答えて

1

ロック解除の時点で、mutexの変更状態をBLOCKEDからREADYにロックしようとしていたすべてのスレッド。特定の実装では、それらのスレッドのうちの1つだけがミューテックスを取得することができますが、その時点で、どのスレッドもミューテックスを試行してロックする可能性があります。

スレッド3は、いくつかの実装で誰かの前にmutexをスワップインして得ることができるかもしれません。

1

トレッドに要求された順序でロックが付与されるという保証はありません。

+0

私はロック取得がFCFSベースであるかどうか尋ねていませんでした。 UNLOCK(m、t1) - > LOCK(m、t4)のシナリオでは、LOCK(m、t1) '。 'UNLOCK(m、t1) 'では、間違いなくt2とt3との間の競合が存在する(すなわち、FCFSではない)可能性がある。私の質問は、t4がロックに競合しすぎていることです(t4は** 'm'がロック解除された後にロック要求**をしました)。 –

+0

UNLOCK(m、t1)の後にACQUIREが存在しない場合は、LOCK(m、t4)を仮定すると論理的になります。 )はmutexのために競争します。これが言って、私は興味があります、あなたが解決しようとしている問題は何ですか? –

+0

POSIXのmutexとスレッドがどのように動作することが予想されるかを理解しようとすると、問題を解決しようとするだけではありません。 –

1

保証はありません。

状況は、スレッド1のロック解除がスレッド3のロックでレースされている場合にのみ発生する可能性があります。その状況では、ロック解除の少し前または少し後にロックが実際には違いはありません。

+0

本当ですか? pthread_cond_signal()とpthread_cond_wait()のケースでは、この問題について混乱があったからです。 David Butenhofは、pthread_cond_signal()がシグナルの前にpthread_cond_wait()を呼び出したスレッドのみを起床させることを明らかにしています。 http://austingroupbugs.net/view.php?id = 609 –

+0

pthread_mutex_unlock()の場合、私がマニュアルページを解釈する方法は、同じ動作がここでも期待されるということでした。つまり、pthread_mutex_unlock()はすでにスレッドを待っているスレッドをブロック解除しようとします。 。 –

+0

ここでの相違点は、条件変数に関連付けられたmutexを保持しているときに 'pthread_cond_signal()'が呼び出された場合、ロックによってブロック解除と待機が順序付けされていることです。したがって、待機が前後どちらに起こったかシグナル。これはあなたの例では当てはまりません - スレッド1のロック解除とスレッド3のロックの間に順序付けの制約はありません。 (おそらく、2番目のミューテックスを使用してこのような制約を作成することもできます)。 – caf

関連する問題