今日面接に行った時、面接官は私に次の質問をしました。
再入可能性と相互排除はスレッドセーフですか? 理由を説明できますか？
私は並行プログラミングに比較的慣れていないので、答えることができませんでした..しかし、私は言った...
相互排除はスレッドセーフです。しかし、再入可能性はそうではありません。それが、再入可能ロックがある理由です。
インタビュアーは次の質問に移りましたが、別の分野でした...私はこれを台無しにしたと思います...
彼が私にこれを尋ねたとき、彼は私が何を言うことを期待していますか?
適切な答えは次のとおりです。
はい、それらはスレッドセーフの実装です。
再入可能
あるタスクによって部分的に実行され、別のタスクによって再入力され、元のタスクから再開されるようにコードを記述すること。これには、静的変数やグローバル変数ではなく、通常はスタック上の各タスクにローカルな変数に状態情報を保存する必要があります。
一例
相互排除
共有データへのアクセスは、常に 1 つのスレッドだけが共有データを読み書きできるようにするメカニズムを使用してシリアル化されます。コードの一部が複数の共有データにアクセスする場合は、細心の注意が必要です。問題には、競合状態、デッドロック、ライブロック、飢餓、および多くのオペレーティング システムの教科書に列挙されているその他のさまざまな問題が含まれます。
一例
どちらもスレッド セーフです。ウィキペディアでも読むことができます:
http://en.wikipedia.org/wiki/Reentrant_(subroutine
)
http://en.wikipedia.org/wiki/Mutual_exclusion
各ロックに対応するロック解除があることが保証されている場合、同じスレッドから複数回ロックされます。
http://en.wikipedia.org/wiki/Reentrant_(サブルーチン)を引用します
再入可能性とスレッド セーフの両方の概念は、関数がリソースを処理する方法に関連しています。ただし、それらは同じではありません。
再入可能性の概念は関数の外部インターフェイスに影響を与える可能性がありますが、スレッド セーフは関数の実装のみに関係し、その外部インターフェイスには関係しません。
-- ほとんどの場合、再入不可の関数を再入可能にするには、すべてのデータが関数の呼び出し元によって提供されるように、その外部インターフェイスを変更する必要があります。
-- スレッドセーフでない関数をスレッドセーフにするには、通常は同期ブロックを追加して、異なるスレッドによる同時アクセスから共有リソースを保護することにより、実装のみを変更する必要があります。
したがって、再入可能性はスレッド セーフよりも基本的なプロパティであり、定義上、スレッド セーフにつながります。すべての再入可能関数はスレッド セーフです。ただし、すべてのスレッドセーフ関数が再入可能というわけではありません。