Valgrind / Helgrind 错误地将 TTAS 模式报告为种族

Question

我想我发现 Helgrind 工具返回的误报类型相当广泛。也许这已在其他地方记录，但似乎 Helgrind 工具总是会错误地将Test and Test-And-Set pattern 检测为误报。

struct resource {
    int in_use;
    int value;
    pthread_mutex_t lock;
}

// assume each member of resource is initialized in the main function
// in_use is initialized to zero
// value is initialized to zero
// and the lock is initialized with pthread_mutex_init() 
struct resource[1000];

void insertIntoUnused(int toInsert) {
    int i;
    for (i = 0; i < 1000; i++) {
        if (resource[i].in_use == 0) {
            pthread_mutex_lock(&resource[i].lock);
            if (resource[i].in_use == 0) {
                resource[i].in_use = 1;
                resource[i].value = toInsert;
                pthread_mutex_unlock(&resource[i].lock);
                return;
            }
            pthread_mutex_unlock(&resource[i].lock);
        }
    }
}

如果许多线程运行上述insertIntoUnused 函数，Helgrind 将在第一次读取in_use 变量时检测到可能的竞争条件。但是，in_use 变量在获取锁后会再次检查，而in_use 变量仅在获取锁时写入。

TTAS 模式是一种非常常见的减少锁竞争的方法。我很惊讶 Helgrind 不能“支持”这种模式。

我了解 Helgrind 算法为何会在此处检测竞争条件。每次读取in_use 变量和每次写入之间都没有happens-before 关系。然而证明上面的代码是正确的并不难（我实际上并没有把它打出来……所以，除了错别字，它在文献中已经很好地确立了）。

如何让 Helgrind 停止考虑第一次检查潜在的竞争条件，以便我可以在我的程序中找到其他竞争条件？

Answer 1

POSIX 线程模型表明，对resource.in_use 的非同步访问会导致未定义的行为，尽管在这种情况下它“看起来还不错”。

理论上，编译器可以利用这一点 - 例如，一旦循环的执行将 resource.in_use 视为非零，它就不需要再次测试它，因为（没有数据竞争）什么都没有在resource.in_use != 0 的情况下，可能会导致该值发生变化。 IE。它可以将其更改为以下内容：

for (i = 0; i < 1000; i++) {
    if (resource.in_use != 0) {
        i = 1000;
        break;
    }

    pthread_mutex_lock(&resource[i].lock);
    if (resource.in_use == 0) {
        resource.in_use = 1;
        resource.value = toInsert;
        pthread_mutex_unlock(&resource[i].lock);
        return;
    }
    pthread_mutex_unlock(&resource[i].lock);
}