什么是while（pthread_mutex_trylock（mutex））

Question

最近，我读的源代码的memcached ，在文件memcached.h 。 我找到了这段代码：

static inline int mutex_lock(pthread_mutex_t *mutex)
{
    while (pthread_mutex_trylock(mutex));
    return 0;
}

我只是想知道为什么不直接使用pthread_mutex_lock 。 上述代码的优点是什么？

在pthread_mutex_trylock看起来更合理之后sleep 1 or 2 seconds因为它不会浪费CPU资源。

有任何想法吗？

谢谢。

Answer 1

这本质上是一个自旋锁。 我们的想法是让线程避免在内核中阻塞，这可能会损害线程的效率。

只有当锁具有相当低的争用率和/或被保持很短的时间时，这种螺旋锁才有意义。 显然，如果你在while循环中旋转一堆迭代，那也会导致效率下降。

另外，我相信libc通常会在阻塞之前通过一点点旋转来实现pthread_mutex_lock() ，但是我必须深入研究（可能很难阅读）源来验证这一点。

另一点 - 这将是在单核系统上运行的非常愚蠢的代码，但那些正在灭绝。

Answer 2

这样，您可以使另一个函数等待资源被解锁。 这也是pthread_mutex_lock的作用。 但是，try_lock可用于防止死锁条件，如优先级反转情况。 由于该函数返回错误而不是阻塞进程（如pthread_mutex_lock那样）。

但我同意这基本上实现了pthread_mutex_lock，区别在于您可以扩展此自定义函数以防止死锁。

编辑：如果你添加一个几秒钟的睡眠btw可能会再次声称资源，因为几秒钟是相对长的时间。 通过不添加睡眠，您可以在可能的情况下强制锁定资源，因此与等待相比更加公平。

假设我们有3个线程B,C,D等待由A锁定的相同资源假设我们分别有1秒的睡眠和B,C,D的到达时间。 0.1, 0.15, 0.2所有三个线程都需要0.25秒的资源（为简单起见）而A需要它0.1秒。 然后，如果每个线程每秒都需要资源，我们可能最终得到A在时间1.0释放资源的情况，那么资源B可以在1.1处声明它并在0.35处释放它，没有其他线程可以声明它因为它们在等待这个时刻。 然后资源A在1.9获得收益并再次声明资源并在2.0释放它。 之后，在时间2.1再次由线程B声明。 这确保了只有资源A和B可以声明资源。 因此，我们得到线程C和D饥饿。

当然这是糟糕的设计，但是你应该在编写函数时从用法中抽象出来以锁定资源。 但是，使用随机睡眠将解决此问题，但您需要再次了解有关资源使用的知识。