【问题标题】:Why does Helgrind show "lock order violated" error message?为什么 Helgrind 显示“违反锁定顺序”错误消息?
【发布时间】:2020-05-25 11:36:04
【问题描述】:

请看以下代码

    #include <stdio.h>
    #include <pthread.h>
    #include <assert.h>
    #include <stdlib.h>

    pthread_mutex_t g = PTHREAD_MUTEX_INITIALIZER;
    pthread_mutex_t m1 = PTHREAD_MUTEX_INITIALIZER;
    pthread_mutex_t m2 = PTHREAD_MUTEX_INITIALIZER;

    void* worker(void* arg) 
    {
        pthread_mutex_lock(&g);

        if ((long long) arg == 0) {
        pthread_mutex_lock(&m1);
        pthread_mutex_lock(&m2);
        } else {
        pthread_mutex_lock(&m2);
        pthread_mutex_lock(&m1);
        }
        pthread_mutex_unlock(&m1);
        pthread_mutex_unlock(&m2);

        pthread_mutex_unlock(&g);
        return NULL;
    }

    int main(int argc, char *argv[]) {
        pthread_t p1, p2;
        pthread_create(&p1, NULL, worker, (void *) (long long) 0);
        pthread_create(&p2, NULL, worker, (void *) (long long) 1);
        pthread_join(p1, NULL);
        pthread_join(p2, NULL);
        return 0;
    }

Helgrind 抛出以下错误:

==10035== Helgrind, a thread error detector
==10035== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al.
==10035== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==10035== Command: ./Hw5
==10035== 
==10035== ---Thread-Announcement------------------------------------------
==10035== 
==10035== Thread #3 was created
==10035==    at 0x538987E: clone (clone.S:71)
==10035==    by 0x5050EC4: create_thread (createthread.c:100)
==10035==    by 0x5050EC4: pthread_create@@GLIBC_2.2.5 (pthread_create.c:797)
==10035==    by 0x4C36A27: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x1088BD: main (Hw5.c:28)
==10035== 
==10035== ----------------------------------------------------------------
==10035== 
==10035== Thread #3: lock order "0x309080 before 0x3090C0" violated
==10035== 
==10035== Observed (incorrect) order is: acquisition of lock at 0x3090C0
==10035==    at 0x4C3403C: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x10882E: worker (Hw5.c:16)
==10035==    by 0x4C36C26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x50506DA: start_thread (pthread_create.c:463)
==10035==    by 0x538988E: clone (clone.S:95)
==10035== 
==10035==  followed by a later acquisition of lock at 0x309080
==10035==    at 0x4C3403C: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x10883A: worker (Hw5.c:17)
==10035==    by 0x4C36C26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x50506DA: start_thread (pthread_create.c:463)
==10035==    by 0x538988E: clone (clone.S:95)
==10035== 
==10035== Required order was established by acquisition of lock at 0x309080
==10035==    at 0x4C3403C: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x108814: worker (Hw5.c:13)
==10035==    by 0x4C36C26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x50506DA: start_thread (pthread_create.c:463)
==10035==    by 0x538988E: clone (clone.S:95)
==10035== 
==10035==  followed by a later acquisition of lock at 0x3090C0
==10035==    at 0x4C3403C: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x108820: worker (Hw5.c:14)
==10035==    by 0x4C36C26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x50506DA: start_thread (pthread_create.c:463)
==10035==    by 0x538988E: clone (clone.S:95)
==10035== 
==10035==  Lock at 0x309080 was first observed
==10035==    at 0x4C3403C: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x108814: worker (Hw5.c:13)
==10035==    by 0x4C36C26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x50506DA: start_thread (pthread_create.c:463)
==10035==    by 0x538988E: clone (clone.S:95)
==10035==  Address 0x309080 is 0 bytes inside data symbol "m1"
==10035== 
==10035==  Lock at 0x3090C0 was first observed
==10035==    at 0x4C3403C: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x108820: worker (Hw5.c:14)
==10035==    by 0x4C36C26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==10035==    by 0x50506DA: start_thread (pthread_create.c:463)
==10035==    by 0x538988E: clone (clone.S:95)
==10035==  Address 0x3090c0 is 0 bytes inside data symbol "m2"
==10035== 
==10035== 
==10035== 
==10035== For counts of detected and suppressed errors, rerun with: -v
==10035== Use --history-level=approx or =none to gain increased speed, at
==10035== the cost of reduced accuracy of conflicting-access information
==10035== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)

我认为外部锁g 不会允许两个线程同时进入临界区。 在给定时间只有一个线程可以获取锁g。所以我认为不可能出现僵局。我穿了吗?为什么 helgrind 会抛出这个错误?请解释一下。

【问题讨论】:

    标签: c multithreading pthreads valgrind deadlock


    【解决方案1】:

    Helgrind 抱怨您的线程被观察到以不同的相对顺序锁定互斥锁 m1m2,这从代码检查中也很清楚。 Helgrind 会在获取顺序中查找并标记此类差异,因为一般来说,它们会产生死锁的风险。

    我认为外锁g不会允许两个线程进入 同时临界区。只有一个线程可以获取锁g 在给定的时间。所以我认为不可能出现僵局。是 我穿了?

    你没有错。给出的特定程序不会死锁,因为每个线程必须先获取g,然后才能获取其他互斥锁。

    为什么 hlgrind 会抛出这个错误?

    因为 helgrind 是对一次运行期间程序运行时行为启发式分析。它并不假定程序的单次运行就展示了所有可能的行为。另一方面,您的评估是基于源代码分析。

    您在此处看到的启发式规则是,任何线程都不应该以不同的相对顺序获取任何一对互斥锁。对于您的特定程序,这会产生误报,但您的程序似乎是专门为产生这种情况而设计的。如果互斥锁g 在获得其他任何一个时始终保持不变,则首先不需要互斥锁m1m2。但是,如果任何其他线程有可能在不持有g 的情况下获取m1m2,那么无论所述其他线程中的获取顺序如何,死锁风险都是真实存在的。

    那么,无论如何,警告表明您的代码存在真正的问题:您正在执行不需要的互斥操作,或者您现在或将来存在真正的死锁风险。

    【讨论】:

      猜你喜欢
      • 2021-03-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-11-10
      • 2011-01-30
      • 2012-12-30
      • 2019-01-30
      相关资源
      最近更新 更多