【问题标题】:sem_destroy a semaphore someone else holds a sem_wait on?sem_destroy 其他人持有 sem_wait 的信号量?
【发布时间】:2012-12-28 22:33:44
【问题描述】:

如果您有一个线程 (thread1) 阻塞在 sem_wait() 上,而另一个线程 (thread2) 使用 sem_destroy() 破坏了该信号量,那么 thread1 会发生什么?

A quick search on the internet tells me that it produces undefined behavior:

销毁其他进程或线程当前被阻塞的信号量(在 sem_wait(3) 中)会产生未定义的行为。

但是,我碰巧看到它在许多多线程 c++ 应用程序中使用。

我的主要问题:

  • 这有什么目的吗?
  • 他们试图达到什么目的(例如,这会隐式终止线程)?
  • 那不是很不安全吗?

【问题讨论】:

  • it just so happens that I've been reading lately many multi-threaded c++ applications from here and there to learn some nice coding practices and I have seen this done multiple times 这并不奇怪。即使您看到它在 linux 内核中完成,也不要依赖未定义的行为。

标签: c++ posix semaphore


【解决方案1】:

在我听说过的任何 API 中,我想不出任何一个案例,其中在使用过程中销毁某物是正常的或已定义的。因此,我认为您的问题的答案是:

那么他们想要达到什么目的呢?

我不知道。

那不是很不安全吗?

是的!

也许您看过的其他程序的作者知道这些实现的实际作用并依赖于它。但他们必须为未来可能发生的变化做好准备。也许他们已经权衡了这种改变破坏他们的程序的风险与他们通过走捷径和依赖未定义的行为所获得的节省,并认为这是值得的。你必须自己做出判断。

【讨论】:

    【解决方案2】:

    这取决于实现。有些会解锁信号量阻塞的进程并将 errno 设置为 EINVAL。有些不会。我在Linux上做了一些实验。结果不一致。有时另一个进程会无限期地阻塞。有时它会被解锁但没有设置 errno。我猜在 Linux 上这确实是一种未定义的行为。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-12-24
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多