mutex死锁分析

最新推荐文章于 2025-05-07 03:48:33 发布
原创 最新推荐文章于 2025-05-07 03:48:33 发布 · 942 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#Android

crash_arm64> ps -l | grep UN
[  2160787611102] [UN]  PID: 1      TASK: ffffff80bb931d80  CPU: 6   COMMAND: "init"
[    35202770595] [UN]  PID: 1008   TASK: ffffff8067f03b00  CPU: 1   COMMAND: "thermald"
[    35173575557] [UN]  PID: 1011   TASK: ffffff8066d31d80  CPU: 0   COMMAND: "charged"
[    29518488925] [UN]  PID: 578    TASK: ffffff80a556bb00  CPU: 1   COMMAND: "health@2.1-serv"
[    16102199938] [UN]  PID: 246    TASK: ffffff80b4fe49c0  CPU: 2   COMMAND: "kworker/u16:8"
[    16102126591] [UN]  PID: 243    TASK: ffffff80b4fe0ec0  CPU: 1   COMMAND: "kworker/u16:5"


crash_arm64> bt 1
PID: 1      TASK: ffffff80bb931d80  CPU: 6   COMMAND: "init"
 #0 [ffffffc01006ba30] __switch_to at ffffffc010229c14
 #1 [ffffffc01006ba80] __schedule at ffffffc0110097ac
 #2 [ffffffc01006bae0] schedule at ffffffc011009dc8
 #3 [ffffffc01006bb00] schedule_preempt_disabled at ffffffc011009e64
 #4 [ffffffc01006bb50] __mutex_lock at ffffffc01100b998
 #5 [ffffffc01006bba0] __mutex_lock_slowpath at ffffffc01100afdc
 #6 [ffffffc01006bbb0] mutex_lock at ffffffc01100afac
 #7 [ffffffc01006bbd0] sc27xx_fgu_set_property$88b22dda440bce0a05d7d0c62e5dc850 at ffffffc00998c51c [sc27xx_fuel_gauge]
 #8 [ffffffc01006bc20] power_supply_set_property at ffffffc010b01190
 #9 [ffffffc01006bc40] charger_manager_shutdown$d53e64e453665dd43ff15e344308be70 at ffffffc00990bea0 [charger_manager]
#10 [ffffffc01006bc80] platform_drv_shutdown$104c53a728511f9c3c65153306e9a61d at ffffffc010916edc
#11 [ffffffc01006bca0] device_shutdown at ffffffc01090dfac
#12 [ffffffc01006bd00] kernel_restart at ffffffc0102c08e4
#13 [ffffffc01006be30] __arm64_sys_reboot at ffffffc0102c0d4c
#14 [ffffffc01006be70] el0_svc_common at ffffffc01023b8ac
#15 [ffffffc01006beb0] el0_svc_handler at ffffffc01023b7dc
#16 [ffffffc01006bff0] el0_svc at ffffffc0100a66c4
     PC: 0000007fa6905020   LR: 0000005563258330   SP: 0000007fc45b73f0
    X29: 0000007fc45b7410  X28: 6f6974616d696e61  X27: 0000007fc45b7541
    X26: b400007de67a5eb8  X25: 0000000000001770  X24: 0000005563149c62
    X23: 0000000000000000  X22: 0000000000000016  X21: 0000007fae6b67f8
    X20: 00000000dead0003  X19: b400007de67a5eb8  X18: 0000007fad57e000
    X17: 0000007fa6905000  X16: 0000005563314d70  X15: 0000000000000000
    X14: 0000000000000010  X13: 00000000e7094360  X12: 0000000000000003
    X11: 0000000000000040  X10: 0000007dc6789000   X9: 0000000000000000
     X8: 000000000000008e   X7: 000000000000000a   X6: 000000000000000a
     X5: 000000000000000a   X4: 0000007fc45b6e32   X3: b400007de67a5eb9
     X2: 00000000a1b2c3d4   X1: 0000000028121969   X0: 00000000fee1dead
    ORIG_X0: 00000000fee1dead  SYSCALLNO: 8e  PSTATE: 40001000


    
crash_arm64> bt 1008
PID: 1008   TASK: ffffff8067f03b00  CPU: 1   COMMAND: "thermald"
 #0 [ffffffc019beb7c0] __switch_to at ffffffc010229c14
 #1 [ffffffc019beb810] __schedule at ffffffc0110097ac
 #2 [ffffffc019beb870] schedule at ffffffc011009dc8
 #3 [ffffffc019beb890] schedule_preempt_disabled at ffffffc011009e64
 #4 [ffffffc019beb8e0] __mutex_lock at ffffffc01100b998
 #5 [ffffffc019beb930] __mutex_lock_slowpath at ffffffc01100afdc
 #6 [ffffffc019beb940] mutex_lock at ffffffc01100afac
 #7 [ffffffc019beb970] sc27xx_fgu_get_property$88b22dda440bce0a05d7d0c62e5dc850 at ffffffc00998bee8 [sc27xx_fuel_gauge]
 #8 [ffffffc019beb9e0] power_supply_get_property at ffffffc010b010f0
 #9 [ffffffc019beba00] is_batt_present at ffffffc009906288 [charger_manager]
#10 [ffffffc019beba50] is_charging at ffffffc0099097bc [charger_manager]
#11 [ffffffc019bebad0] charger_get_property$d53e64e453665dd43ff15e344308be70 at ffffffc00990dd88 [charger_manager]
#12 [ffffffc019bebb40] power_supply_get_property at ffffffc010b010f0
#13 [ffffffc019bebb60] power_supply_show_property$585d20bcb1be35037d56665a6c5c3de1 at ffffffc010b0243c
#14 [ffffffc019bebbd0] dev_attr_show$f317772e3afc67365624a70905d4b42c at ffffffc01090f15c
#15 [ffffffc019bebbf0] sysfs_kf_seq_show$940b66a61121dfe2d682373570bf778e at ffffffc010587810
#16 [ffffffc019bebc50] kernfs_seq_show$321396c22fae547781b1d29c056a00a9 at ffffffc0105868b4
#17 [ffffffc019bebc70] seq_read at ffffffc0104ff4f8
#18 [ffffffc019bebce0] kernfs_fop_read$321396c22fae547781b1d29c056a00a9 at ffffffc010585734
#19 [ffffffc019bebdb0] __vfs_read at ffffffc0104c9538
#20 [ffffffc019bebdd0] vfs_read at ffffffc0104c9850
#21 [ffffffc019bebe20] ksys_read at ffffffc0104c9f58
#22 [ffffffc019bebe60] __arm64_sys_read at ffffffc0104c9fe0
#23 [ffffffc019bebe70] el0_svc_common at ffffffc01023b8ac
#24 [ffffffc019bebeb0] el0_svc_handler at ffffffc01023b7dc
#25 [ffffffc019bebff0] el0_svc at ffffffc0100a66c4
     PC: 00000071e443bf88   LR: 00000061620cfd5c   SP: 0000007fefa6fb50
    X29: 0000007fefa6fba0  X28: b400007124007168  X27: 00000061620d29cc
    X26: b4000070c3fe7c30  X25: 00000061620c07f3  X24: 0000000000000000
    X23: b400006fe3ff30d0  X22: 0000007fefa6fb50  X21: 00000071ecc44010
    X20: b400007003fe5410  X19: 0000000000000005  X18: 00000071eda86000
    X17: 00000071e443bf80  X16: 00000061620d18f0  X15: 0000000000000000
    X14: 0000000000000010  X13: 0000007fefa6f0fa  X12: 0000000000000001
    X11: 00000071e43c4a82  X10: 0000000000000000   X9: 0b7d208cc4bd1b27
     X8: 000000000000003f   X7: 7f7f7f7f7f7f7f7f   X6: fefefefefefefeff
     X5: 8080808080808080   X4: 0000000000000000   X3: 0000000000000000
     X2: 0000000000000040   X1: 0000007fefa6fb50   X0: 0000000000000005
    ORIG_X0: 0000000000000005  SYSCALLNO: 3f  PSTATE: 60001000


crash_arm64> bt 1011
PID: 1011   TASK: ffffff8066d31d80  CPU: 0   COMMAND: "charged"
 #0 [ffffffc019bfb880] __switch_to at ffffffc010229c14
 #1 [ffffffc019bfb8d0] __schedule at ffffffc0110097ac
 #2 [ffffffc019bfb930] schedule at ffffffc011009dc8
 #3 [ffffffc019bfb950] schedule_preempt_disabled at ffffffc011009e64
 #4 [ffffffc019bfb9a0] __mutex_lock at ffffffc01100b998
 #5 [ffffffc019bfb9f0] __mutex_lock_slowpath at ffffffc01100afdc
 #6 [ffffffc019bfba00] mutex_lock at ffffffc01100afac
 #7 [ffffffc019bfba30] sc27xx_fgu_get_property$88b22dda440bce0a05d7d0c62e5dc850 at ffffffc00998bee8 [sc27xx_fuel_gauge]
 #8 [ffffffc019bfbaa0] power_supply_get_property at ffffffc010b010f0
 #9 [ffffffc019bfbad0] charger_get_property$d53e64e453665dd43ff15e344308be70 at ffffffc00990de58 [charger_manager]
#10 [ffffffc019bfbb40] power_supply_get_property at ffffffc010b010f0
#11 [ffffffc019bfbb60] power_supply_show_property$585d20bcb1be35037d56665a6c5c3de1 at ffffffc010b0243c
#12 [ffffffc019bfbbd0] dev_attr_show$f317772e3afc67365624a70905d4b42c at ffffffc01090f15c
#13 [ffffffc019bfbbf0] sysfs_kf_seq_show$940b66a61121dfe2d682373570bf778e at ffffffc010587810
#14 [ffffffc019bfbc50] kernfs_seq_show$321396c22fae547781b1d29c056a00a9 at ffffffc0105868b4
#15 [ffffffc019bfbc70] seq_read at ffffffc0104ff4f8
#16 [ffffffc019bfbce0] kernfs_fop_read$321396c22fae547781b1d29c056a00a9 at ffffffc010585734
#17 [ffffffc019bfbdb0] __vfs_read at ffffffc0104c9538
#18 [ffffffc019bfbdd0] vfs_read at ffffffc0104c9850
#19 [ffffffc019bfbe20] ksys_read at ffffffc0104c9f58
#20 [ffffffc019bfbe60] __arm64_sys_read at ffffffc0104c9fe0
#21 [ffffffc019bfbe70] el0_svc_common at ffffffc01023b8ac
#22 [ffffffc019bfbeb0] el0_svc_handler at ffffffc01023b7dc
#23 [ffffffc019bfbff0] el0_svc at ffffffc0100a66c4
     PC: 0000007858c7ef88   LR: 000000590cb4934c   SP: 00000075c8afbc20
    X29: 00000075c8afbc40  X28: 000000590cb48d04  X27: b400007788b8ac58
    X26: 000000590cb48962  X25: 000000590cb48cd8  X24: 00000075c8afbd00
    X23: 0000000000000004  X22: 0000000062c9874d  X21: 000000590cb48a4c
    X20: 000000590cb488c8  X19: 000000590cb4890f  X18: 00000075c8016000
    X17: 0000007858c7ef80  X16: 000000590cb4a2f8  X15: 0000000000000000
    X14: 0000000000000101  X13: 000000003f47a8cd  X12: 0000ffff00000eff
    X11: 00000000000003f3  X10: 00000000000003f3   X9: ffcb4b5da4a67caf
     X8: 000000000000003f   X7: 0000000062c9874d   X6: 0000000062c9874d
     X5: 0000000000000008   X4: 00000075c8afbc30   X3: 0000000000000000
     X2: 0000000000000004   X1: 00000075c8afbc28   X0: 0000000000000004
    ORIG_X0: 0000000000000004  SYSCALLNO: 3f  PSTATE: 60001000


    

    crash_arm64> bt 246
PID: 246    TASK: ffffff80b4fe49c0  CPU: 2   COMMAND: "kworker/u16:8"
 #0 [ffffffc012b33720] __switch_to at ffffffc010229c14
 #1 [ffffffc012b33770] __schedule at ffffffc0110097ac
 #2 [ffffffc012b337d0] schedule at ffffffc011009dc8
 #3 [ffffffc012b337f0] schedule_preempt_disabled at ffffffc011009e64
 #4 [ffffffc012b33840] __mutex_lock at ffffffc01100b998
 #5 [ffffffc012b33890] __mutex_lock_slowpath at ffffffc01100afdc
 #6 [ffffffc012b338a0] mutex_lock at ffffffc01100afac
 #7 [ffffffc012b338d0] sc27xx_fgu_get_property$88b22dda440bce0a05d7d0c62e5dc850 at ffffffc00998bee8 [sc27xx_fuel_gauge]
 #8 [ffffffc012b33940] power_supply_get_property at ffffffc010b010f0
 #9 [ffffffc012b33960] rt9471_charger_stop_charge at ffffffc0099a7198 [rt9471_charger]
#10 [ffffffc012b33ba0] rt9471_charger_usb_set_property$ffe1b4e6d23e367e0a866e046d2a2623 at ffffffc0099a7fa0 [rt9471_charger]
#11 [ffffffc012b33c20] power_supply_set_property at ffffffc010b01190
#12 [ffffffc012b33c40] try_charger_enable_by_psy at ffffffc009906d80 [charger_manager]
#13 [ffffffc012b33ca0] try_charger_enable at ffffffc009905d0c [charger_manager]
#14 [ffffffc012b33d10] _cm_monitor at ffffffc009905964 [charger_manager]
#15 [ffffffc012b33d60] cm_monitor_poller$d53e64e453665dd43ff15e344308be70 at ffffffc009904f38 [charger_manager]
#16 [ffffffc012b33d90] process_one_work at ffffffc0102b5338
#17 [ffffffc012b33e00] worker_thread$f31e2447a3fdcb60f4b193f95acd647c at ffffffc0102b590c
#18 [ffffffc012b33e60] kthread$bdfae7274f17a094019e62b74615f335 at ffffffc0102bb8c8
#19 [ffffffc012b33ec0] ret_from_fork at ffffffc0100a67ec


crash_arm64> bt 243
PID: 243    TASK: ffffff80b4fe0ec0  CPU: 1   COMMAND: "kworker/u16:5"
 #0 [ffffffc012b1b880] __switch_to at ffffffc010229c14
 #1 [ffffffc012b1b8d0] __schedule at ffffffc0110097ac
 #2 [ffffffc012b1b930] schedule at ffffffc011009dc8
 #3 [ffffffc012b1b950] schedule_preempt_disabled at ffffffc011009e64
 #4 [ffffffc012b1b9a0] __mutex_lock at ffffffc01100b998
 #5 [ffffffc012b1b9f0] __mutex_lock_slowpath at ffffffc01100afdc
 #6 [ffffffc012b1ba00] mutex_lock at ffffffc01100afac
 #7 [ffffffc012b1ba20] rt9471_charger_usb_get_property$ffe1b4e6d23e367e0a866e046d2a2623 at ffffffc0099a78dc [rt9471_charger]
 #8 [ffffffc012b1ba80] power_supply_get_property at ffffffc010b010f0
 #9 [ffffffc012b1bab0] sc27xx_fgu_capacity_calibration at ffffffc00998df08 [sc27xx_fuel_gauge]
#10 [ffffffc012b1bb50] sc27xx_fgu_get_capacity at ffffffc00998d890 [sc27xx_fuel_gauge]
#11 [ffffffc012b1bbd0] sc27xx_fgu_get_property$88b22dda440bce0a05d7d0c62e5dc850 at ffffffc00998c2b4 [sc27xx_fuel_gauge]
#12 [ffffffc012b1bc40] power_supply_get_property at ffffffc010b010f0
#13 [ffffffc012b1bd20] cm_batt_works$d53e64e453665dd43ff15e344308be70 at ffffffc00990c570 [charger_manager]
#14 [ffffffc012b1bd90] process_one_work at ffffffc0102b5338
#15 [ffffffc012b1be00] worker_thread$f31e2447a3fdcb60f4b193f95acd647c at ffffffc0102b590c
#16 [ffffffc012b1be60] kthread$bdfae7274f17a094019e62b74615f335 at ffffffc0102bb8c8
#17 [ffffffc012b1bec0] ret_from_fork at ffffffc0100a67ec


 
crash_arm64> struct mutex ffffff80b902b110 -x
struct mutex {
  owner = {
    counter = 0xffffff80b4fe49c1
  },
  wait_lock = {
    {
      rlock = {
        raw_lock = {
          {
            val = {
              counter = 0x0
            },
            {
              locked = 0x0,
              pending = 0x0
            },
            {
              locked_pending = 0x0,
              tail = 0x0
            }
          }
        }
      }
    }
  },
  osq = {
    tail = {
      counter = 0x0
    }
  },
  wait_list = {
    next = 0xffffffc012b1b978,
    prev = 0xffffffc01bb439c8
  }
}


crash_arm64> struct task_struct 0xffffff80b4fe49c0 | grep pid
  pid = 246,


crash_arm64_v8.0.1_unisoc> search -t ffffff80b902b110
PID: 243    TASK: ffffff80b4fe0ec0  CPU: 1   COMMAND: "kworker/u16:5"
ffffffc012b1b960: ffffff80b902b110
ffffffc012b1b9e8: ffffff80b902b110

PID: 246    TASK: ffffff80b4fe49c0  CPU: 2   COMMAND: "kworker/u16:8"
#9 [ffffffc012b33960] rt9471_charger_stop_charge at ffffffc0099a7198 [rt9471_charger]
    ffffffc012b33960: ffffffc012b33ba0 ffffffc0099a7fa4 
    ffffffc012b33970: ffffffc012b33c30 0000000000000000 
    ffffffc012b33980: ffffff80b902b080 ffffff80b902b110 

结论:
process 246存在自锁，mutex lock了两次，请check自己的充电驱动。
 

buck1237
关注
【std::mutex】互斥量死锁
突围
01-30 558
std::mutex
一次Mutex死锁的原因探究
shengyin714959的博客
10-07 166
到了这里，原因就非常明了了，由于log输出在项目中使用非常频繁，而写log时又需要重复调用fopen()和fclose打开关闭文件，这对IO的操作是比较费时间的，导致某些线程在此处由于等待超时被终止(由于其他Mutex是可跨进程的，所以其他进程中的线程意外终止或进程未正常退出都会有此问题)，进而导致Mutex未被释放处于废弃状态。这里再次深刻的警示，线程是不能随意终止的，同时频繁打开关闭文件操作也是不合理的，正确的做法应该是打开一次后保存文件句柄，再程序退出时再关闭。dump中在调用!
Linux内核深度解析之中断、异常和系统调用——系统调用
linuxweiyh的博客
06-21 2935
系统调用 系统调用是内核给用户程序提供的编程接口。用户程序调用系统调用，通常使用glibc库针对单个系统调用封装的函数。如果glibc库没有针对某个系统调用封装的函数，用户程序可以使用通用的封装函数syscall()： #define _GNC_SOURCE #include <unistd.h> #include <sys/syscall.h> /* 定义SYS_xxx */ long syscall(long number, ...); 参数number是
第四十二期-ARM Linux内核的系统调用（2）
智能软件研究中心的博客
06-23 1642
作者：罗宇哲，中国科学院软件研究所智能软件研究中心 上一期中我们介绍了ARM Linux内核中的系统调用和定义系统调用的流程，这一期我们将介绍系统调用的执行过程。 一、ARM Linux内核中系统调用的执行过程 在第二十九期和第三十期中，我们介绍过ARM Linux内核中的异常向量表和异常处理的一般流程。系统调用属于同步异常的范畴，因此遵循异常处理的一般流程。ARM Linux 内核的异常向量表在/kernel-4.19/arch/arm64/kernel/entry.S文件中： 该表从上到下共有四组，系
mutex死锁问题排查
weixin_45609638的博客
05-27 2193
使用gdb $ g++ -g -O0 -fno-omit-frame-pointer ./test.cc -o test -lpthread $./test before lock_guard 重新开启一个终端，打开gdb $ sudo gdb attach $(pidof test) GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2 Copyright (C) 2020 Free Software Foundation,
linux_线程锁mutex(互斥量)_线程同步_死锁现象_pthread_mutex_lock函数_pthread_mutex_unlock函数_死锁现象
qq_44177918的博客
05-01 2095
线程锁，pthread_mutex_lock函数 pthread_mutex_unlock函数 当T1再次获得cpu继续 从失去cpu的位置向后写入1，当执行结束，内存中的100字节，既不是全1，也不是全0。4、main 中加n= 10 将n在while中-- 这时，主线程输出10次后退出，调用pthread_cancel()将子线程退出，销毁锁。以上3点中，前两点不能改变，欲提高效率，传递数据，资源必须共享。unlock主动解锁函数，同时将阻塞在该锁上的所有线程全部唤醒，至于哪个线程先被唤醒，取决于优先
Golang Mutex死锁检测与调试技巧
Golang编程笔记的博客
05-07 1147
在Golang的并发编程中，Mutex（互斥锁）是一种常用的同步原语，用于保护共享资源，防止多个协程同时访问而导致数据竞争。然而，不正确地使用Mutex可能会导致死锁问题，即两个或多个协程相互等待对方释放锁，从而使程序陷入无限等待状态。本文的目的是深入探讨Golang中Mutex死锁的检测与调试技巧，帮助开发者识别、定位和解决死锁问题。范围涵盖了Mutex的基本概念、死锁的产生原因、常见的检测方法以及有效的调试技巧。本文将按照以下结构进行组织：首先介绍Mutex的核心概念和相关联系，包括其原理和架构；
kdump+crash 解决休眠锁(mutex)死锁问题
paul1994的博客
10-10 1023
环境：arm64，Linux version 5.10.66。
mutex死锁参考代码
最新发布
09-06
以下是不同编程语言中 mutex 死锁的参考代码示例： ### Golang 中的 mutex 死锁示例 ```go package main import ( "fmt" "sync" ) var ( mutex1 sync.Mutex mutex2 sync.Mutex ) func goroutine1() { mutex...
Linux Mutex机制与死锁分析
一个带你入门的嵌入式开发“老者”
12-08 3414
在Linux系统上,Mutex机制相比于信号量,实现更加简单和高效,但使用也更加严格 1. 任何时刻只有一个任务可以持有Mutex 2. 谁上锁谁解锁 3. 不允许递归地上锁和解锁 4. 当进程持有一个Mutex时,不允许退出 5. Mutex只能通过相关API来管理,不可被拷贝,手动初始化或重复初始化 在应用层来说,一般Mutex多用于多线程间的同步,本文针对第四点"当进程持有一个Mutex时,不允许退出"来做一些探讨和测试 关于多进程使用Mutex,有一个很经典的场景,即共享内存通讯 两
[C++11 并发编程] 07 - Mutex 死锁
yaming的专栏
08-15 5589
假设有两个线程，在执行某些操作时，都需要锁定一对mutex，线程A锁定了mutex A，而线程B锁定了额mutex B，它们都在等待对方释放另一个mutex，这就会导致这两个线程都无法继续执行。这种情况就是死锁。 避免死锁最简单的方法是总是以相同的顺序对两个mutex进行锁定，比如总是在锁定mutex B之前锁定mutex A，就永远都不会死锁。 假设有一个操作要交换同一个类的两个实例的内容，
Linux之线程-互斥量mutex与死锁
qq_42041303的博客
02-28 412
**主要内容：（1）互斥量及如何使用 （2）什么是死锁，如何解决 （3）什么是读写锁，如何使用** （4）条件变量实现的生产消费者模型 （5）信号量实现的生产消费者模型 **线程同步** 协调步骤，顺序执行。解决同步的问题：加锁！ 数据混乱的原因： - 资源共享（独享资源则不会）； - 随机调度（意味着数据访问会出现竞争）； - 线程间缺乏必要的同步机制。（解决该点最为可行，因此需要用到互斥量） **1.mutex互斥量** 两个线程访问同一块共享资源，如果不协调顺序，容易造成数据混乱。解决方...
什么是死锁？怎么排查死锁？怎么避免死锁？
小林coding
04-01 6070
突然发现我的图解系统缺了「死锁」的内容，这就来补下。 在面试过程中，死锁也是高频的考点，因为如果线上环境真多发生了死锁，那真的出大事了。 这次，我们就来系统地聊聊死锁的问题。 死锁的概念； 模拟死锁问题的产生； 利用工具排查死锁问题； 避免死锁问题的发生； 死锁的概念 在多线程编程中，我们为了防止多线程竞争共享资源而导致数据错乱，都会在操作共享资源之前加上互斥锁，只有成功获得到锁的线程，才能操作共享资源，获取不到锁的线程就只能等待，直到锁被释放。 那么，当两个线程为了保护两个不同的共享资源而使用了两个
多线程编程中关于“死锁”的相关概念问题
日常记录，挨打要立正！
10-12 911
死锁的条件，与饥饿、死循环的异同，如何避免死锁
C++多线程：mutex互斥量与死锁（五）
weixin_43808717的博客
03-30 1060
互斥量是一个类对象，理解成一把锁，多个线程尝试用lock()成员函数来加锁这把锁头（成功的标志是lock()函数的返回，不成功将一直阻塞在这把锁上）。而std::lock批量获取锁后为了忘记释放，可以在std::lock_guard中添加参数std::adopt_lock使得在在析构时自动释放锁。这个是std::lock_guard的源码，可以看到lock_guard的源码很简单，在构造时加锁，互斥量需要小心使用，数据（临界区）不能过多或者过少的保护，过少有安全问题，过多有效率问题。
Qt signals与QMutexLocker产生死锁问题
Jason的技术探索与分享
08-06 2128
为数据的线程安全，使用QMutex加锁，界面出现卡死现象，排查发现产生了死锁{}{}{});QMutexLocker 的作用域是{}内部，所以setName()函数中对一个valueChanged()信号也进行了加锁，emit 信号时并没有解锁，此时使用connect连接的函数又调用resultMap()再次加锁，多次加锁产生了死锁完整代码如下：.h.cpp调用关系。......
mutex死锁追踪
Abrave_2007的专栏
08-27 990
void debug_mutex_init(gs_mutex_t *mutex, void *data) {     pthread_mutex_init(&mutex->mutex, data);     mutex->file[0]='\0';     mutex->line = 0; } void debug_mutex_destroy(gs_mutex_t *mutex
理解线程互斥锁mutex引起的死锁
u014285914的博客
05-07 1703
理解线程互斥锁mutex引起的死锁
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值