5

我看到在极少数情况下会pthread_cond_timedwait()返回EINVAL并导致我们的系统发生致命崩溃。我知道这意味着传入的参数之一必须无效，但是 mutex 或 cond 变量如何变得无效？

有没有办法在调用之前检查这些参数pthread_cond_timedwait()以防止崩溃？

4

2 回答 2

13

没有明确说明什么是无效的，但这里有一些我观察到的pthread_cond_timedwait返回原因EINVAL：

  • 条件和/或互斥锁未正确初始化。检查初始化返回结果，并验证是否显式链接了正确的 pthread 库。链接各种版本的 glibc 时可能会出现零星问题，导致 init 调用返回成功但对象未正确初始化的情况难以调试。
  • 任何未定义的行为都可能导致无效的内部状态，pthread 调用可能检测到也可能检测不到。未定义的行为可能来自：
    • 多次初始化互斥锁或条件变量而不破坏它。
    • 在它被销毁之后，但在它被重新初始化之前使用互斥锁或条件变量。
    • 条件和/或互斥锁由应用程序代码手动覆盖。
    • 线程等待对象时，互斥锁或条件变量被破坏。
  • 不同的互斥锁与相同的条件变量一起使用。
  • abstime参数的tv_nsec 值小于 0 或大于 1,000,000,000。

如果不手动模仿 pthread 正在执行的验证调用，那么我不知道在调用之前检查参数的方法pthread_cond_timewait()。但是，pthread_cond_timewait()返回EINVAL不应导致致命崩溃，因为它是特定情况。考虑检查可能无法正确处理返回结果的应用程序代码的其他区域。例如，只要返回不是就假定成功的代码ETIMEDOUT。

于 2012-07-03T22:56:36.403 回答
5

我想分享一下我在这个问题上的经验，时间值是'timespec'，它的'tv_nsec'范围应该保持在[0, 999999999]内，因此如果你将nano值设置为超过1秒，一些linux可能会返回 EINVAL！

struct timespec {
    time_t tv_sec;      /* Seconds */
    long   tv_nsec;     /* Nanoseconds [0 .. 999999999] */ 
};

希望这能帮助你摆脱困境。

于 2013-07-02T08:02:37.007 回答