ubuntu:sem_timedwait没有醒来(C)
我有3个需要同步的进程。进程一做某事然后唤醒进程二并休眠,这会做一些事情然后唤醒进程三并休眠,这会做一些事情并唤醒进程并休眠。整个循环定时运行大约25hz(在我的“真实”应用程序中触发进程2之前,由外部同步进入进程1)。我使用sem_post来触发(唤醒)每个进程,并使用sem_timedwait()来等待触发器。
这一切都成功地工作了几个小时。但是在某个随机时间(通常在两到四个小时之后),其中一个进程在sem_timedwait()中开始超时,即使我确定使用sem_post()触发了信号量。为了证明这一点,我甚至在超时后立即使用sem_getvalue(),并且值为1,因此应该触发timedwait。
请参阅以下代码:
#include <stdio.h>
#include <time.h>
#include <string.h>
#include <errno.h>
#include <semaphore.h>
sem_t trigger_sem1, trigger_sem2, trigger_sem3;
// The main thread process. Called three times with a different num arg - 1, 2 or 3.
void *thread(void *arg)
{
int num = (int) arg;
sem_t *wait, *trigger;
int val, retval;
struct timespec ts;
struct timeval tv;
switch (num)
{
case 1:
wait = &trigger_sem1;
trigger = &trigger_sem2;
break;
case 2:
wait = &trigger_sem2;
trigger = &trigger_sem3;
break;
case 3:
wait = &trigger_sem3;
trigger = &trigger_sem1;
break;
}
while (1)
{
// The first thread delays by 40ms to time the whole loop.
// This is an external sync in the real app.
if (num == 1)
usleep(40000);
// print sem value before we wait. If this is 1, sem_timedwait() will
// return immediately, otherwise it will block until sem_post() is called on this sem.
sem_getvalue(wait, &val);
printf("sem%d wait sync sem%d. val before %dn", num, num, val);
// get current time and add half a second for timeout.
gettimeofday(&tv, NULL);
ts.tv_sec = tv.tv_sec;
ts.tv_nsec = (tv.tv_usec + 500000); // add half a second
if (ts.tv_nsec > 1000000)
{
ts.tv_sec++;
ts.tv_nsec -= 1000000;
}
ts.tv_nsec *= 1000; /* convert to nanosecs */
retval = sem_timedwait(wait, &ts);
if (retval == -1)
{
// timed out. Print value of sem now. This should be 0, otherwise sem_timedwait
// would have woken before timeout (unless the sem_post happened between the
// timeout and this call to sem_getvalue).
sem_getvalue(wait, &val);
printf("!!!!!! sem%d sem_timedwait failed: %s, val now %dn",
num, strerror(errno), val);
}
else
printf("sem%d wakeup.n", num);
// get value of semaphore to trigger. If it's 1, don't post as it has already been
// triggered and sem_timedwait on this sem *should* not block.
sem_getvalue(trigger, &val);
if (val <= 0)
{
printf("sem%d send sync sem%d. val before %dn", num, (num == 3 ? 1 : num+1), val);
sem_post(trigger);
}
else
printf("!! sem%d not sending sync, val %dn", num, val);
}
}
int main(int argc, char *argv[])
{
pthread_t t1, t2, t3;
// create semaphores. val of sem1 is 1 to trigger straight away and start the whole ball rolling.
if (sem_init(&trigger_sem1, 0, 1) == -1)
perror("Error creating trigger_listman semaphore");
if (sem_init(&trigger_sem2, 0, 0) == -1)
perror("Error creating trigger_comms semaphore");
if (sem_init(&trigger_sem3, 0, 0) == -1)
perror("Error creating trigger_vws semaphore");
pthread_create(&t1, NULL, thread, (void *) 1);
pthread_create(&t2, NULL, thread, (void *) 2);
pthread_create(&t3, NULL, thread, (void *) 3);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
pthread_join(t3, NULL);
}
当程序正确运行时(在开始时和随机但很长时间后)打印以下输出。 sem1的值在thread1等待40ms之前始终为1,此时sem3已触发它,因此它会立即唤醒。其他两个线程一直等到从前一个线程收到信号量。
[...]
sem1 wait sync sem1. val before 1
sem1 wakeup.
sem1 send sync sem2. val before 0
sem2 wakeup.
sem2 send sync sem3. val before 0
sem2 wait sync sem2. val before 0
sem3 wakeup.
sem3 send sync sem1. val before 0
sem3 wait sync sem3. val before 0
sem1 wait sync sem1. val before 1
sem1 wakeup.
sem1 send sync sem2. val before 0
[...]
但是,几个小时后,其中一个线程开始超时。我可以从输出中看到信号量被触发,当我在超时后打印该值时,它是1.所以sem_timedwait应该在超时之前很好地唤醒。在超时之后我永远不会期望信号量的值为1,除非在超时之后但在我调用sem_getvalue之前触发发生非常罕见的场合(几乎肯定从不但可能)。
此外,一旦它开始失败,该信号量上的每个sem_timedwait()也会以相同的方式失败。请参阅以下输出,我已对其进行了编号:
01 sem3 wait sync sem3. val before 0
02 sem1 wakeup.
03 sem1 send sync sem2. val before 0
04 sem2 wakeup.
05 sem2 send sync sem3. val before 0
06 sem2 wait sync sem2. val before 0
07 sem1 wait sync sem1. val before 0
08 !!!!!! sem3 sem_timedwait failed: Connection timed out, val now 1
09 sem3 send sync sem1. val before 0
10 sem3 wait sync sem3. val before 1
11 sem3 wakeup.
12 !! sem3 not sending sync, val 1
13 sem3 wait sync sem3. val before 0
14 sem1 wakeup.
[...]
在第1行,线程3(我在printf中混淆地称为sem3)等待触发sem3。在第5行,thread2为sem3调用sem_post。但是,第8行显示sem3超时,但信号量的值为1. thread3然后触发sem1并再次等待(10)。但是,因为该值已经为1,所以它会立即唤醒。它不再发送sem1,因为这一切都发生在对thread1给出控制之前,然后它再次等待(val现在为0)并且sem1唤醒。这现在重复,sem3总是超时并显示值为1。
所以,我的问题是为什么sem3超时,即使信号量已被触发且值明显为1?我永远不会期望在输出中看到第08行。如果它超时(因为,假设线程2已经崩溃或花费太长时间),则该值应为0.为什么它在进入此状态之前首先工作3或4小时?
我尝试过使用三个独立程序进行类似测试,通过共享内存进行通信,而不是同一程序中的三个线程。这更类似于我的真实世界应用程序。结果和输出是一样的。问题确实出现在信号量(特别是sem_timedwait调用)中,而不是与pthreads有关。
我也尝试过更短和更长的延迟,以及完全消除延迟,结果与上述类似。没有任何延迟,它有时会在几分钟而不是几小时后开始产生错误。这当然意味着可以更快地再现问题。
这是使用Ubuntu 9.4和内核2.6.28。相同的程序在Redhat和Fedora上运行正常,但我现在正试图移植到Ubuntu。我也试过使用Ubuntu 9.10,没有任何区别。
谢谢你的建议,
贾尔斯
没有找到相关结果
已邀请:
6 个回复
久纳禾澎
(注意添加=)然后它工作正常。这是另一个问题,为什么信号量的状态(大概)会消失,以便在后续尝试中超时,或者直接在sem_wait上直接阻塞。看起来像libc或内核中的错误。
畦桨存灯
线程3是计划的或其他什么 它需要达到
线程2醒来并完成它
在
线程3发出它的
并看到1 线程3分支错误 分支,并没有做它的
在
这种竞争条件很难触发,基本上你必须达到一个小的时间窗口,其中一个线程在等待信号量时遇到问题,然后用
读取信号量。该条件的发生在很大程度上取决于环境(系统类型,内核数量,负载,IO中断),因此这解释了为什么它只在数小时后发生,如果不发生的话。 控制流量取决于
通常是个坏主意。对
的唯一原子非阻塞访问是通过
和
。 所以这个问题的示例代码具有竞争条件。这并不意味着吉尔兹的原始问题代码确实具有相同的竞争条件。也许这个例子太简单了,对他来说仍然表现出同样的现象。 我的猜测是,在他最初的问题中,有一个没有保护的
。这是一个
,仅检查其返回值,如果失败则不检查
。如果过程有一些IO,
确实在
上发生。如果遇到
,你只需要检查并重置
即可做
。
温拎凯玛
田眯衅
开始 在
来回,你是 寻找麻烦。使用
如果你必须这样做,但在这里 没有理由通过真实的 指向值的指针。
和一些更精明的演员会为C99做诀窍。
是另一个麻烦点。右侧可能与左侧的宽度不同。做 ts.tv_nsec = tv.tv_usec; ts.tv_nsec + = 500000; sem系列函数不是中断安全的。这样的中断可能由IO触发,因为你正在执行printf等。检查
左右的返回值是不够的,但在这种情况下你应该检查
并决定你是否要重试。然后,如果你想要精确的话,你必须重新计算剩余的时间和类似的东西。然后,
的手册页列出了可能出现的不同错误代码及其原因。 您还可以从值中得出结论 你通过
获得。在一个 多线程/多进程/多处理器 你的线程可能有的环境 在返回之间没有计划 来自
和
。基本上你不能 从变量中推导出任何东西 只是偶然的价值 你观察到的不要从中得出结论。
茂坦湿床够
并获得1 线程n + 1从
返回,信号量变为0 线程n决定不发布,信号量保持为0 现在,我看不出这是如何触发观察到的行为的。毕竟,因为线程n + 1无论如何被唤醒,它将依次唤醒线程n + 2,这将唤醒线程n等... 虽然有可能出现故障,但我看不出这会如何导致线程系统超时。
款去芳尾脊
与此同时,我也在浏览器中玩Java游戏(由stackoverflow用户发布,寻找反馈,有趣的转移:) - 所以jvm有可能负责搔痒某些内容以冻结我的机器。