中文版如下图：
上面那句：
- 这样其他线程试图对这个互斥量的加锁就会被堵塞
是错误的，应该是同一个线程。相当与于说，同一个线程在信号处理程序之前调用了一次getenv_r，加了一次锁，然后信号来了，又在信号处理程序中调用getenv_r，又加了一次锁。那么如果不是递归锁，就会死锁。所以必须要递归锁。
另付上英文原版为证明：
If we make getenv_r thread-safe, that doesn't mean that it is reentrant with respect to signal handlers. If we use a nonrecursive mutex, we run the risk that a thread will deadlock itself if it calls getenv_r from a signal handler. If the signal handler interrupts the thread while it is executing getenv_r, we will already be holding env_mutex locked, so another attempt to lock it will block, causing the thread to deadlock. Thus, we must use a recursive mutex to prevent other threads from changing the data structures while we look at them, and also prevent deadlocks from signal handlers. The problem is that the pthread functions are not guaranteed to be async-signal safe, so we can't use them to make another function async-signal safe.
If we make getenv_r thread-safe, that doesn't mean that it is reentrant with respect to signal handlers. If we use a nonrecursive mutex, we run the risk that a thread will deadlock itself if it calls getenv_r from a signal handler. If the signal handler interrupts the thread while it is executing getenv_r, we will already be holding env_mutex locked, so another attempt to lock it will block, causing the thread to deadlock. Thus, we must use a recursive mutex to prevent other threads from changing the data structures while we look at them, and also prevent deadlocks from signal handlers. The problem is that the pthread functions are not guaranteed to be async-signal safe, so we can't use them to make another function async-signal safe.
扫一扫
1394
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
