在Unix/Linux系統中，signal是以軟中斷的方式分發的，signal handler可能在任何時候打斷一個程序的任意一個執行緒而執行（如果該執行緒沒有遮蔽該signal的話）。

比如，pthread_mutex_lock函式顯然是執行緒安全的，但是它不是非同步可重入的，考慮下面的情況，有這麼一段程式碼：

pthread_mutex_lock(&gLock);

change_some_thing();

pthread_mutex_unlock(&gLock);

假定有一個工作執行緒A執行到這段程式碼，呼叫了pthread_mutex_lock但是還沒返回的時候，有個signal產生了，signal handler打斷執行緒A執行，然後在signal handler的上下文中也執行到了這段程式碼（注意signal handler其實借用了執行緒A的棧執行程式碼，這一點很像作業系統核心的中斷處理），signal handler呼叫pthread_mutex_lock的時候，執行緒A的pthread_mutex_lock可能才執行了一半，因為pthread_mutex_lock不是非同步可重入的，所以在signal handler的上下文中的pthread_mutex_lock呼叫很可能會破壞pthread_mutex_t的內部狀態，導致程式死鎖等異常行為。

類似的情況還有很多，最後導致的結果也不盡相同。

不過非同步可重入應該是Unix/Linux這種支援signal的系統特有的。在Windows下，其實並不存在類似的問題，Windows的C Runtime雖然也有signal這樣的函式，但是它更像是為了保持向前相容而做的模擬，因為Windows的signal是透過特定的執行緒分發的，所以它不會打斷應用的執行緒。所有執行緒安全的函式在Windows的signal handler中應該都可以使用。在Windows中，SEH機制更接近Unix/Linux中的signal handler，但是顯然SEH更可控一點。

個人並不喜歡Unix/Linux中的signal機制，Unix/Linux中的signal機制更像是一種使用者態的中斷，當它和多執行緒機制同時出現的時候，總是顯得格格不入。