这是一种竞争条件吗？

Question

竞争条件的定义:竞争条件或竞争风险是系统或过程中的缺陷，过程的输出或结果出乎意料地严重依赖于其他事件的顺序或时间。

考虑下面的伪代码：

    Global variable i initialized to 6;
    Thread 1: 
        acquire(lock l)
        increment global variable i, i.e. i++;

    Thread 2: 
       acquire(lock l)
       double the value of global var i, i.e.: i*=2;

如果T1首先获取锁l，然后是T2，则i的值将是14。另一方面，如果T2首先获取锁l，然后是T1，则i的值将是13。

那么，这是不是一个竞态条件？

更新:在一系列评论和答案之后，意见仍然存在分歧。我的观点是“是的，这是一种竞争条件”。实际上，我在不同的问题上给出了这个例子作为竞争条件的情况。同时，我也在“不，这不是比赛条件”类别中读到了一些有趣的评论。我想我会解决并得出结论，这是或不是一个竞态条件，取决于一个人看待问题的角度/水平。然而，我仍然在等待有趣的答案/评论。

Answer 1

我认为示例算法是否具有竞争条件取决于算法的预期功能。

在i的修改上没有数据竞争-这些访问是序列化的，并且彼此之间以原子方式发生。

然而，如果递增发生在乘法之前对算法的正确性很重要(反之亦然)，那么就必须使用竞争和其他方法来同步算法的执行。如果算法被认为是一种计算i * 2 + 1的复杂方法(尽管使用线程执行计算可能很荒谬)，那么就存在竞争条件。

考虑下面的程序片段：

int data;

pthread_cond_t condvar = PTHREAD_COND_INITIALIZER;
pthread_mutex_t mux = PTHREAD_MUTEX_INITIALIZER;

void* wait_for_data(void*)
{
    pthread_mutex_lock( &mux);
    pthread_cond_wait( &condvar, &mux);

    puts("got the data: %d\n", data);

    pthread_mutex_unlock( &mux);

    return 0;
}


void* set_data(void*)
{
    pthread_mutex_lock( &mux);

    data = 42;

    pthread_cond_signal( &condvar);

    pthread_mutex_unlock( &mux);

    return 0;
}

这两个线程本质上是完全互斥的--没有数据竞争。但是，如果set_data()在wait_for_data()等待条件变量之前用信号通知它，wait_for_data()将永远不会完成。我认为大多数人会将其称为竞态条件，因为条件变量使用不当。

Answer 2

不，不是。因为它在读和写i之前锁定。所以你的例子中的读和写总是一致的。当然，您应该在每次操作后解锁，但我猜您只是忘了在伪代码中添加它。

Answer 3

不，这是预期的执行序列之一。竞争不会通过某种类型的锁来保护计数器，从而允许加载-修改-存储周期并发运行。

编辑0：

@Gheorghe，想一个联合银行账户的例子，两个人同时在不同的银行办公室取钱。每个地点的职员都需要检查帐户余额，发放现金，并写下新的余额。如果这不是关于余额的“原子”，即帐户在此操作期间没有“锁定”，他们可能最终在其中两个人之间获得比他们在银行中的钱更多的钱。银行不喜欢这样。

但是，如果帐户在被操纵时被锁定，输出是否取决于时间？是的，绝对-总和不会改变，但它们之间的分割可以是不同的。

重要的是受保护价值的一致性-无论这两个人以什么顺序和多少次从背后拿到钱，他们都不会比最初得到更多。