私の知見によれば、ミューテックスをロックするプロセスは、ミューテックスのロックを解除する必要があります。私の疑問は プロセッサがどのプロセスをロック解除するかを知っていますか？pid（または）何かを保存するデータ構造はありますか？ waitqueでは特定のプロセス（内部的に）、つまり、プロセッサは特定のプロセスのロックを解除するだけです。mutexでは、プロセッサ（CPU）がロックを解除するプロセスをどのように知っていますか？
私のインタビューの1つで、このd個の質問に返信してください。
ミューテックスを取得したスレッド/プロセスは、コード内を前進する唯一のスレッド/プロセスです。そのスレッドのコードの後に、mutexのリリースがあるはずです。ミューテックスを持たない他のスレッド/プロセスは、1つの実行プロセスがミューテックスリリースに到達するまで、ミューテックスを受け取ったりリリースしたりしないように待機します。
どのプロセッサがロックを解除するプロセスを知っていますか？
プロセッサは何も知らない。それは、提供された機械命令のチェーンを盲目的に実行するだけです。
スレッディングライブラリは、この種の問題を処理するために慎重に設計されています。また、現代/マルチタスクOSには、ブート時にメモリにロードされるスレッドスケジューラが含まれており、実行されるスレッドとそのタイミングを管理します。これは、ロック/ロック解除の問題を正しく処理するためにスレッドライブラリと一緒に機能します。
したがって、問題は次のようになります。OSソフトウェアは、mutexのロックが解除されたときに、次に起動するスレッドをどのように知っていますか？
実際の実装はOSによって異なりますが、概念的には、リンクリストを含む各mutexオブジェクトを想像することができます。スレッドが既にロックされているmutexをロックしようとすると、スケジューラはスレッドをスリープ状態にするようスケジューラに指示します。
その後、ロック解除ルーチンは、リンクされたリストから最初のスリープスレッド（ある場合）をポップし、そのスレッドにmutexの所有権を再割り当てし、そのスレッドはできるだけ早く。
（警告：競合状態を避けてパフォーマンスを最大化する必要があるため、現実世界の実装はおそらくこれよりも少し複雑になるでしょうが、これでどのようにできるかというアイデアが得られたと思いますこの例の実装では、スレッドはlock（）を呼び出したのと同じ順序で先取り/最初の処理でミューテックスを取得しますが、実際の実装では順序が保証されていないため、あなたはそれに頼るべきではありません）
ありがとうございました...私はあなたが実際にそのスレッドにmutexの所有権を再割り当てすると言いましたか？ @Jeremy Friesner – sravanthi
@sravanthi一度に1つのスレッドだけがmutexを保持します。ミューテックスを保持するスレッドは、ミューテックスの所有者と呼ばれます。 lock（）がスレッドで返されると、そのスレッドがmutexの所有者であることが保証されます。したがって、スレッドAがmutexの所有者であり、スレッドAがmutexでunlock（）を呼び出すため、スレッドBがlock（）内で待機している場合、その時点でスレッドBはmutexの所有者になり、スレッドBのlock（）スレッドBが実行を再開できるように、呼び出しが返されます。 –
あなたのご返信ありがとうございました... @ Jeremy Friesner – sravanthi
mutexを待っているスレッド/プロセスがカーネルによってスケジュールされて、自明の "テストと設定" CPUコマンドを実行してミューテックスを試してみる方法を聞いていますか？私は、どのスレッドがmutexを最初に取得するかについて何らかの保証があるとは信じていないので、これの複数の機能実装が存在する可能性があります。 –