问题标签 [semaphore]

信号量是一个经常用于解决多线程问题的编程概念。我对社区的问题：

什么是信号量以及如何使用它？

二进制信号量和互斥量之间有什么区别还是它们本质上是一样的？

pthread_cond_wait使用或使用信号量的优点/缺点是什么？我正在等待这样的状态变化：

使用正确初始化的信号量，我想我可以这样做：

每种方法的优缺点是什么？

在 VxWorks 中，我正在使用 SEM_INVERSION_SAFE 选项创建一个互斥锁，以防止出现优先级反转问题。
手册说我还必须使用 SEM_PRIORITY_Q 选项。这是为什么？

我们有 3 个任务以不同的优先级运行：A (120)、B (110)、C (100)。A 采用带有 Inversion Safe 标志的互斥信号量。任务 B 执行 semTake，这导致任务 A 的优先级提升到 110。稍后，任务 C 执行 semTake。任务 A 的优先级现在是 100。

此时，A 释放信号量，C 抓住它。我们注意到 A 的优先级并没有回到原来的 120 优先级。A 的优先级不应该马上恢复吗？

我想防止我的脚本一次运行不止一次。

我目前的做法是

• 创建一个包含正在运行进程的 pid 的信号量文件
• 读取文件，如果我的进程 ID 不在其中退出（你永远不知道......）
• 在处理结束时，删除文件

为了防止进程挂起，我设置了一个 cron 作业来定期检查文件是否旧于允许的最大运行时间，如果它仍在运行，则终止该进程。

我是否有杀死错误进程的风险？

有没有更好的方法来整体执行此操作？

使用有什么好处吗

java.util.concurrent.CountdownLatch

代替

java.util.concurrent.Semaphore ?

据我所知，以下片段几乎是等价的：

1.信号量

2：倒计时锁存器

除了在 #2 的情况下，闩锁不能被重用，更重要的是，您需要提前知道将创建多少线程（或者等到它们都启动后再创建闩锁。）

那么在什么情况下闩锁可能更可取呢？

一个相当基本的问题，但我没有看到它在任何地方被问到。

假设我们有一个全局结构（在 C 中），如下所示：

我似乎很清楚，如果我们有很多线程读写，我们需要一个信号量（或其他锁）在written_frequently成员上，即使是读取，因为我们不能 100% 确定这个结构的分配是原子的.

如果我们想要很多线程来读取read_only成员，而没有线程来写入，那么我们是否需要在结构访问上设置一个信号量来读取？

（我倾向于说不，因为不断更改之前和之后的位置这一事实不应该影响read_only成员，并且读取该值的多个线程不应该相互干扰。但我不确定。 )

[编辑：我现在意识到我应该更好地问这个问题，以便非常具体地澄清我的意思。当然，当我第一次问这个问题时，我并没有真正理解所涉及的所有问题。当然，如果我现在全面编辑问题，我会毁掉所有这些好答案。我的意思更像是：

我问的主要问题是，由于这些数据是结构的一部分，它是否会受到其他结构成员的影响，是否会反过来影响它们？

事实上，成员是整数，因此写入可能是原子的，在这种情况下实际上只是一个红鲱鱼。]

有没有办法直接从命令提示符更改 Unix 系统上信号量的所有权和权限掩码，而无需部署semctl使用该IPC_SET选项调用的特殊程序？

我有两个 Slackware Linux 系统，POSIX 信号量sem_open()调用失败，errno 设置为 38。下面重现的示例代码（代码在 CentOS / RedHat 上运行良好）。

是否有任何内核或系统配置选项可能导致此问题？其他建议？

有问题的系统是 Slackware 10.1.0 内核 2.6.11 /lib/librt-2.3.4.so /lib/libpthread-0.10.so，但相同的代码适用于更旧的 RedHat 9 内核 2.4.20 /lib/librt -2.3.2.so /lib/tls/libpthread-0.29.so。（也适用于 CentOS 5 内核 2.6.18 /lib/librt-2.5.so /lib/i686/nosegneg/libpthread-2.5.so）。

man sem_opensem_open()表明系统不支持此 errno 方法。

sem_open()用户空间是librt我们动态链接的地方，并且存在librt于受影响的系统上。

受影响的系统声称支持 POSIX 信号量：_POSIX_SEMAPHORES是真的并sysconf(_SC_SEMAPHORES)证实了这一点。

谢谢，基兰

编辑 1：我添加了有关正在使用的软件版本的更多详细信息，并删除了一些不相关的评论。

编辑 2： /dev/shm 安装在好的系统上，而不是安装在坏的系统上。安装它并没有改变受影响系统上的行为。我认为 /dev/shm 也是必要的，但 sem_open() 在此之前失败了，并且 strace 支持这一点。