如果你有一个线程 (thread1) 在 a 上阻塞,sem_wait()
而另一个线程 (thread2) 正在破坏那个信号量,使用sem_destroy()
,那么 thread1 会发生什么?
销毁其他进程或线程当前被阻塞的信号量(在 sem_wait(3) 中)会产生未定义的行为。
但是,我碰巧看到它在许多多线程 c++ 应用程序中使用。
我的主要问题:
- 这有什么目的吗?
- 他们试图实现什么(例如,这会隐式终止线程)?
- 那不是很不安全吗?
如果你有一个线程 (thread1) 在 a 上阻塞,sem_wait()
而另一个线程 (thread2) 正在破坏那个信号量,使用sem_destroy()
,那么 thread1 会发生什么?
销毁其他进程或线程当前被阻塞的信号量(在 sem_wait(3) 中)会产生未定义的行为。
但是,我碰巧看到它在许多多线程 c++ 应用程序中使用。
我的主要问题:
在我听说过的任何 API 中,我想不出任何一个案例,其中在使用过程中销毁某物是正常的或已定义的。因此,我认为您的问题的答案是:
那么他们想要达到什么目的呢?
我不知道。
那不应该很不安全吗?
是的!
也许你看过的其他程序的作者知道这些实现实际上做了什么并且依赖它。但他们必须为未来可能发生的变化做好准备。也许他们已经权衡了这种改变破坏他们的程序的风险与他们通过走捷径和依赖未定义的行为所获得的节省,并认为这是值得的。你必须自己做出这个判断。
这取决于实施。有些会解锁信号量阻塞的进程并将 errno 设置为 EINVAL。有些不会。我在Linux上做了一些实验。结果不一致。有时另一个进程会无限期地阻塞。有时它会被解锁但没有设置 errno。我猜在 Linux 上这确实是一种未定义的行为。