sem_waitとシグナルハンドラ

Question

sem_waitをシグナルハンドラ（特にスレッドごとのSIGSEGVシグナル）で使用できないのはなぜですか？誰かがアプリケーションをクラッシュさせるシナリオの例を教えてもらえますか？私はsem_waitがリエントラントとの両方であり、スレッドセーフであると思います、ここで何が問題なのですか？なぜそれがない非同期の安全？

Answer 1

セマフォの値が0のときにアプリケーションが信号を受信し、その信号を受信したスレッドがセマフォの値（sem_post）をインクリメントすると思われる場合はどうなりますか？シグナルハンドラでsem_waitを呼び出すと、プロセスはデッドロックしますか？

もちろん、sem_waitが非同期シグナルセーフな関数のリストにない場合、実装は無料で鼻の悪魔を呼び出すことができます。

Answer 2

非同期セーフは、スレッドセーフではなく厳しい要件です。クリティカルセクションでグローバルデータを保護するために、プリミティブを使用してスレッドセーフなコードを書くことができます。シグナルハンドラはこれに頼ることはできません。たとえば、sem_wait内のクリティカルセクション内に存在することができ、同時にセグメンテーションの原因となるものを実行できます。これにより、sem_waitのスレッドセーフな保護が解除されます。

Answer 3

sem_waitは、このような理由のためにシグナルハンドラ内で使用することはできません。

スレッドAはSEM1にsem_wait呼び出しです。スレッドAが終了すると、スレッドAはsem1にポストします。ただし、終了する前にシグナルを受信して​​からハンドラに入り、sem1でsem_waitを呼び出します。 Aはsem1にポストするものなので、ハンドラは決して戻ってこないので、デッドロックが発生します。これがシグナルハンドラの中で何かを待つのは良い規則です。問題は、ASFAIKは、クラッシュよりもデッドロックと関連があります。

また、シグナルハンドラの理想的な目的に違反します。これは、外部割り込みを処理して、すぐにやっていたことに戻ることです。

最後に、SIGSEGVを処理するのではなく、SIGSEGVを取り除くのがより良い目標ですか？