问题PTHREAD同步问题 [英] Problem with pThread sync issue

问题描述

我面临着一个pthread的同步问题。 threadWaitFunction1，是一个线程等待功能。
我希望号线。 247 标志= 1 要243-246结束后才执行。
但我觉得奇怪的是，有时，它直接跳转到247 243-246之前已经完成。

I am facing a sync issue with pthread. threadWaitFunction1, is a thread wait function. I expect line no. 247 flag = 1 to be executed only after 243-246 has finished. But i find it strange that sometimes, it jumps directly to 247 before 243-246 has finished.

请帮我。

先谢谢了。

236   struct timespec timeToWait;
237   static void* threadWaitFunction1(void *timeToWaitPtr)
238   {
239       cout << "Setting flag =0 inside threadWaitFunction1\n";
240       
241       cout << "Inside threadWaitFunction\n";
242       struct timespec *ptr = (struct timespec*) timeToWaitPtr;
243       pthread_mutex_lock(&timerMutex);
          flag = 0;
244       pthread_cond_timedwait(&timerCond, &timerMutex, ptr);
          flag=1;
245       pthread_mutex_unlock(&timerMutex);
246       cout << "Setting flag =1 inside threadWaitFunction1\n";
247       
248
249    }

创建并调用上面的线程的线程是：

The thread which creates and calls the above thread is:

263  static void timer_trackStartTime ()
264  {
265       struct timeval now;
266       pthread_t thread;
267       
268       printf("Inside trackStartTime: flag = %d\n",flag);
269 
270      /* Setting timer expiration */
271       timeToWait.tv_sec = lt_leak_start_sec;;  // First expiry after 1 sec
272       timeToWait.tv_nsec = lt_leak_start_nsec;
273       pthread_create(&thread, NULL, threadWaitFunction1, &timeToWait);
274       pthread_join(thread, NULL);
275       //pthread_kill(thread, SIGKILL); // Destroying the thread to ensure no leaks
276 
.
.
283       }

如果我保护的pthread_mutex_lock使用全功能，但还是同样的问题仍然存在。如何保证有序的执行？谁能帮助？

编辑：now.tv_sec和now.tv_nsec从code删除
*的编辑：改变了互斥（仍然不工作）内部的标志的*

推荐答案

所以它不是真正的执行顺序（这是最可能是正确的），但时间，让你不高兴。并在直接跳转到247 243-246结束之前的你的意思是我发现它执行247的时间之前就应该在244等待已经过去了。对吧？

So it is not really execution ordering (which is most probably correct) but timing that makes you unhappy. And under "it jumps directly to 247 before 243-246 has finished" you mean "I observed it executing 247 before the time it should wait in 244 has passed". Right?

然后，我怀疑这是问题的虚假唤醒：在一个线程可能会被唤醒即使没有其他线程信号的条件变量。 的规格那么pthread_cond_timedwait（） 说：可能会从那么pthread_cond_timedwait）杂散唤醒（或pthread_cond_wait（）的功能。

Then, I suspect this is the problem of spurious wakeup: a thread might get woken up even though no other thread signalled the condition variable. The specification of pthread_cond_timedwait() says that "Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur."

一般，条件变量与应用程序中的特定事件相关联，并且一个线程等待事实上条件变量等待由另一个线程感兴趣的事件已经发生的信号。如果没有事件，只是想等待一定的时间，确实是其他方式，如 usleep（）函式或定时器，是比较合适的，除非你还需要一个pthread的取消点。

Usually, a condition variable is associated with a certain event in the application, and a thread waiting on a condition variable in fact waits for a signal by another thread that the event of interest has happened. If you have no event and just want to wait for a certain amount of time, indeed other ways, such as usleep() or timers, are more appropriate, except if you also need a pthread cancellation point.

您的期望，我决定不发布code。如果你需要它，你可以使用@Hasturkun的答案。

ADDED: Since you seem satisfied with usleep() and only asked why pthread_cond_timedwait() did not work to your expectations, I decided not to post the code. If you need it, you may use the answer of @Hasturkun.

补时2：在下面的评论的输出（Hasturkun的溶液涂后获得）表明，等待线程不会退出循环，这可能意味着那么pthread_cond_timedwait（）返回的东西比ETIMEDOUT不同。你见过由@nos评论到您的文章（我固定nanosecs的减去金额）：

ADDED-2: The output in comments below (obtained after the solution of Hasturkun was applied) suggests that the waiting thread does not exit the loop, which likely means that pthread_cond_timedwait() returns something different than ETIMEDOUT. Have you seen the comment by @nos to your post (I fixed the amount of nanosecs to subtract):

确认（now.tv_usec * 1000）+ lt_leak_start_nsec;不会溢出。您只能设置tv_nsec为最大999999999，如果EX pression比大，您应该从tv_nsec减去10亿，并以1递增tv_sec如果timeToWaitPtr包含无效tv_nsec（大于999999999），那么pthread_cond_timedwait将失败（你应该检查它的返回值了。） - 在19点04号4月28日

Make sure (now.tv_usec * 1000) + lt_leak_start_nsec; doesn't overflow. You can only set tv_nsec to max 999999999, if the expression is larger than that, you should subtract 1000000000 from tv_nsec, and increment tv_sec by 1. If your timeToWaitPtr contains an invalid tv_nsec (larger than 999999999), pthread_cond_timedwait will fail (you should check its return value too.) – nos Apr 28 at 19:04

在这种情况下，那么pthread_cond_timedwait（）将反复返回 EINVAL ，将永远走不出的循环。这是更好地进入等待循环之前调整超时，虽然它也可以在响应中做 EINVAL 。

In this case, pthread_cond_timedwait() will repeatedly return EINVAL and will never get out of the loop. It is better to adjust the timeout before entering the wait loop, though it can also be done in response to EINVAL.

补时3：你在你的问题改变了code通过超时而不会增加当前时间后，现在，它还有另一个问题。正如规范，超时为那么pthread_cond_timedwait（）是绝对时间，而不是相对的;所以，当你通过像3秒的超时值，它是作为PTED因为参考点，为系统时间3秒。除$ P $。那一刻，几乎可以肯定是经过了一段时间，所以那么pthread_cond_timedwait（）立即返回。结果
我建议您阅读彻底规范（包括原理）来构建更好的理解这个功能应该是怎样被使用。

ADDED-3: Now after you changed the code in your question to pass the timeout without adding to current time, it has another problem. As stated in the spec, the timeout for pthread_cond_timedwait() is absolute time, not relative; so when you pass something like 3 sec as the timeout, it is interpreted as "3 seconds since the reference point for the system time". That moment is almost certainly passed for a while, and so pthread_cond_timedwait() returns immediately.
I would recommend you to read the specification thoroughly (including rationale) to build better understanding of how this function is supposed to be used.

这篇关于问题PTHREAD同步问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！