如果 sigwait() 阻塞，什么时候接受的信号实际上是 "selected"？

Question

有两个实时线程。第一个具有低优先级，它正在等待 sigwait() 中所有可能的信号（因此所有信号都被阻止并且传递给函数的 sigmask 已启用所有信号）。第二个具有高优先级并向第一个（低优先级）线程发送两个信号 - 它首先发送 SIGRTMAX 然后 SIGRTMIN.

POSIX sigwait() ( http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html ) 的规范是这样说的：

If no signal in set is pending at the time of the call, the thread shall be suspended until one or more becomes pending.

[...]

Should any of the multiple pending signals in the range SIGRTMIN to SIGRTMAX be selected, it shall be the lowest numbered one.

实时操作系统中的事件序列如下所示：

(H)...............signal(SIGRTMAX)===signal(SIGRTMIN)===...
(L)===sigwait().........................................===
      ^           ^                  ^                  ^
      1           2                  3                  4

(H) - 高优先级线程
(L) - 低优先级线程
. - 线程不是运行ning
= - 线程是运行ning

4个有趣的点：

低优先级线程在 sigwait() 上阻塞，当前没有信号挂起，所有信号都被阻塞，高优先级线程尚未启动；
高优先级线程启动并向低优先级线程发送 SIGRTMAX 信号，低优先级线程未被阻塞，但不允许运行，因为高优先级线程仍在运行ning;
高优先级线程继续运行ning 并向低优先级线程发送 SIGRTMIN 信号，但低优先级线程仍在等待运行;
高优先级线程终止，允许低优先级线程从 sigwait() 调用运行和 return；

现在的问题是，如果SIGRTMIN和SIGRTMAX信号同时挂起，SIGRTMIN应该是第一个"selected"。但是我不确定信号实际上是 "selected" 的哪一点 - 它是由内核在“2”处 selected 还是由 [=12] 中的代码 selected =] 在低优先级线程中执行，所以在“4”？这就是为什么我不确定在上面的场景中，sigwait() 调用实际上是 select SIGRTMIN 还是 SIGRTMAX。也许这样的细节是"implementation defined"?

问题与我正在开发的微控制器的实时操作系统有关 (https://github.com/DISTORTEC/distortos)。目前我的代码 "selects" 生成期间的信号，所以在“2”（我的代码将 return SIGRTMAX 首先），但我不再确定这是正确的方法。 ..

Answer 1

我认为场景描述的是一场比赛。所以，好吧，结果是实现定义的。

信号不应用于同步。如果接收两个信号的顺序（对应用程序）很重要，它应该采取适当的操作来同步（它们）。

如果 sigwait() 阻塞，什么时候接受的信号实际上是 "selected"？

If sigwait() blocks, when is the accepted signal actually "selected"?

c

multithreading

posix

signals

rtos