-
本版专家分：106结帖率 95.2% -
各位好，网上阅读一篇文章，有如下一段话：
std::mutex 的成员函数
构造函数，std::mutex不允许拷贝构造，也不允许 move 拷贝，最初产生的 mutex 对象是处于 unlocked 状态的。
lock()，调用线程将锁住该互斥量。线程调用该函数会发生下面 3 种情况：
(1). 如果该互斥量当前没有被锁住，则调用线程将该互斥量锁住，直到调用 unlock之前，该线程一直拥有该锁。
(2). 如果当前互斥量被其他线程锁住，则当前的调用线程被阻塞住。
(3). 如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)。
，对其中的第三条
(3). 如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)。
不是完全理解，它和第一种情况感觉没什么区别
如果该互斥量当前没有被锁住，则调用线程将该互斥量锁住，直到调用 unlock之前，该线程一直拥有该锁。
mutex被当前线程调用lock()锁住之后，怎么会产生死锁呢
多谢！
-
本版专家分：205
-
- Github 绑定github第三方账户获取
-
-
其实很简单，我举个例子你就明白了。
#include <iostream>
#include <mutex>
class myTestMutex
{
public:
myTestMutex(int m_m) : m(m_m) {}
~myTestMutex() {}
void Add(int number)
{
m_mutex.lock();
m += number;
m_mutex.unlock();
}
void PlusOne()
{
m_mutex.lock();
Add(1);
m_mutex.unlock();
}
private:
std::mutex m_mutex;
int m;
};
int main()
{
myTestMutex test(0);
//调用Add方法是没有问题的，而且有原子操作的效果。
test.Add(10);
//但是一定调用PlusOne方法就出现问题了，因为进入PlusOne方法的时候会调用m_mutex.lock()方法，
//还没有调用m_mutex.unlock()方法就马上进入Add方法了，然后Add方法马上又调用了m_mutex.lock()，
//然后m_mutex.lock()因为前面在PlusOne方法调用m_mutex.lock()方法，所以就出现阻塞，然后在Add方法就走不下去了，
//然后因为PlusOne方法调用了Add方法，所以导致PlusOne方法也走不下去了，出现死锁了。
test.PlusOne();
}
虽然c++11有递归互斥量来解决上面代码中的问题，但是这个递归互斥量会比较消耗资源，所以建议尽量在设计代码的时候处理掉这些问题
-
本版专家分：111
-
如果同一线程重复调用同一个std::mutex，中间没有unlock，就会死锁，原因是std::mutex不是递归锁，换成递归锁std::recursive_mutex就可。
void mythread::dealock() {
std::mutex g_pages_mutex;
std::lock_guard<std::mutex> guard(g_pages_mutex);
std::lock_guard<std::mutex> guard(g_pages_mutex); // 这里死锁
}
void mythread::nondealock() {
std::mutex g_pages_mutex;
std::lock_guard<std::recursive_mutex> guard(g_pages_mutex);
std::lock_guard<std::recursive_mutex> guard(g_pages_mutex); // 这里不会死锁
}
-
本版专家分：3853
-
-
红花
2019年3月 C/C++大版内专家分月排行榜第一
2018年12月 C/C++大版内专家分月排行榜第一
-
- 蓝花 2019年2月 C/C++大版内专家分月排行榜第三
-
-
(2). 如果当前互斥量被其他线程锁住，则当前的调用线程被阻塞住。
(3). 如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)。
这两个连起来看就好解释了。一个互斥量被锁住的时候，另一个线程只能被阻塞，等待别的线程释放之后才能在锁住。举个例子：线程好比是水，互斥量好比是水桶，每一个线程用水加满水桶，执行完任务之后再负责把水倒掉；水桶里有水的情况下，其他线程想用，只能等着。现在出现了一个这样的线程，它自己加满的水，出于某些原因在水没倒掉的情况下，它又想用这个桶装新的一种水，就形成了它自己等待自己的情况，也就形成了所谓的死锁。
- C++11线程指南(8)--死锁
- 1. <em>死锁</em> 在多个<em>mutex</em>存在的时候，可能就会产生<em>死锁</em>。 避免<em>死锁</em>的一个最通用的方法是，总是按照相同的顺序来lock the two <em>mutex</em>es， 即总是先于<em>mutex</em> B之前lock <em>mutex</em> A，这样就不会有<em>死锁</em>的可能。有时，这种方法很简单实用，当这些<em>mutex</em>es用于不同的目标。但是，当<em>mutex</em>es用于包含相同类的一个实例时，就不是那么容易了。 例如，如下面程序所
- c++11 防止死锁的一种方式
- struct BankAccount { BankAccount(int b) : Balance(b) {} int Balance; <em>mutex</em> Mutex; }; void transferMoney(BankAccount&a, BankAccount& b, int money) { lock(a.Mutex, b.Mutex); //将锁需要锁住的临界体全部...
- Boost.mutex连续两次加锁会造成死锁
- 问题代码如下：#include&lt;iostream&gt; #include&lt;iomanip&gt; using namespace std; #include &lt;boost/thread.hpp&gt; #include &lt;boost/bind.hpp&gt; #include &lt;boost/thread/<em>mutex</em>.hpp&gt; ...
- c 递归锁(重入锁) pthread_cond_wait 死锁
- //1 thread pthread_<em>mutex</em>_lock(&<em>mutex</em>); pthread_<em>mutex</em>_lock(&<em>mutex</em>); pthread_cond_wait(&cond, &<em>mutex</em>); pthread_<em>mutex</em>_unlock(&<em>mutex</em>); pthread_<em>mutex</em>_unlock(&<em>mutex</em>); //2 thread pthread_<em>mutex</em>
- WinDbg -- 调试互斥体(Mutex)死锁
- 一. 演示用例#include <windows.h> #include <tchar.h> #include <process.h>HANDLE hMutexA = NULL; HANDLE hMutexB = NULL;unsigned __stdcall ThreadProc1(void * pArg) { WaitForSingleObject(hMutexA, INFINITE);
- 信号量（semaphore），互斥锁（mutex）解决哲学家死锁问题
- /* author : youfl func : 哲学家吃饭问题 descript : 哲学家吃饭<em>死锁</em>问题，会产生<em>死锁</em>的主要原因是哲学家会同时拿起左边的筷子 同时都在等右边的筷子释放，此处可以使用信号量，控制资源数量为总资源数 量NUM - 1,在已经有NUM - 1 的筷子被使用的情况下，就不能有人再拿左边的 筷子了进而保证哲学家不能同时
- Linux C/C++ 多线程死锁的gdb调试方法
- <em>死锁</em>的原因就不多说了，本质上，就是有一些线程在请求锁的时候，永远也请求不到。 先把有<em>死锁</em>的多线程代码贴出来 #include #include #include #include #include pthread_<em>mutex</em>_t g_s<em>mutex</em> ; void * func(void *arg) { int i=0; //lock pthread_mut
- 用gdb脚本解决死锁的调试方法(由pthread_mutex_lock引起的死锁)
- 首先给出gdb定位<em>死锁</em>的脚本： #deadlock_debug_gdb.cmd set pagination off set logging file gdb.log set logging overwrite set logging on start set $lock_addr=pthread_<em>mutex</em>_lock set $unlock_addr=pthread_<em>mutex</em>
- Boost.mutex递归访问同一把锁造成死锁
- <em>mutex</em>虽然可以很好地协调线程同步，互斥访问全局变量。但不慎使用，也可能会造成<em>死锁</em>。下面这段代码就演示了递归访问同一把锁造成的<em>死锁</em>：#include&lt;iostream&gt; #include&lt;iomanip&gt; using namespace std; #include &lt;boost/thread.hpp&gt; #include &lt;boost/bind.hp...
- pthread_mutex_lock造成死锁原因
- 刚刚接触linux不久，在多线程编程时遇到了互斥锁<em>死锁</em>的情况，分析原因是同一个锁连续两次加锁，导致程序被锁死。
- c++ 11 多线线程系列----mutex
- Mutex 又称互斥量，C++ <em>11</em>中与 Mutex 相关的类（包括锁类型）和函数都声明在 头文件中，所以如果你需要使用 std::<em>mutex</em>，就必须包含 头文件。 头文件介绍 Mutex 系列类(四种) std::<em>mutex</em>，最基本的 Mutex 类。std::recursive_<em>mutex</em>，递归 Mutex 类。std::time_<em>mutex</em>，定时 Mutex 类。st
- 1线程同步：互斥量，死锁
- 1线程为什么要同步 A:共享资源，多个线程都可对共享资源操作。 B:线程操作共享资源的先后顺序不确定。 C:处理器对存储器的操作一般不是原子操作。 2互斥量 <em>mutex</em>操作原语 pthread_<em>mutex</em>_t pthread_<em>mutex</em>_init pthread_<em>mutex</em>_destroy pthread_<em>mutex</em>_lock
- 调试死锁（deadlock）的方法
- 如果程序运动不正常的时候，可以利用pstack看一下程序当然的状态，多次执行如下： [tangliang]$ pstack 31859 Thread 3 (Thread 0x7f69b59d2700 (LWP 31860)): #0 0x000000380220e264 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000
- 一个多线程的死锁和锁争用的例子
- 在多线程编程中，为了保持同步，需要使用互斥锁保护临界区，但是多线程共同使用互斥锁的时候会造成<em>死锁</em>或者锁争用的情况： <em>死锁</em>： 产生<em>死锁</em>的原因主要是： （1） 因为系统资源不足。 （2） 进程运行推进的顺序不合适。 （3） 资源分配不当等。 如果系统资源充足，进程的资源请求都能够得到满足，<em>死锁</em>出现的可能性就很低，否则 就会因争夺有限的资源而陷入<em>死锁</em>。其次，进程运行推进顺序与速度不同，也可
- C++11Mutex（互斥锁）详解
- 多个线程访问同一资源时，为了保证数据的一致性，最简单的方式就是使用 <em>mutex</em>（互斥锁）。（1）.直接操作 <em>mutex</em>，即直接调用 <em>mutex</em> 的 lock / unlock 函数。此例顺带使用了 boost::thread_group 来创建一组线程。#include &lt;iostream&gt; #include &lt;boost/thread/<em>mutex</em>.hpp&gt; #includ...
- golang 中 锁的错误的用法会导致死锁。
- package main import ( "sync" "time" . "github.com/soekchl/myUtils" ) var mux sync.RWMutex func tt() { Notice() mux.Lock() // 3 Notice() defer mux.Unlock() time.Sleep(time.Second * 5) } f
- 死锁之锁顺序
- 1、由于不同线程对两个锁获取的顺序不一致造成的<em>死锁</em>，叫做锁顺序<em>死锁</em>。2、代码示例如下：/** * LeftRightDeadlock * * Simple lock-ordering deadlock * * @author Brian Goetz and Tim Peierls */ public class LeftRightDeadlock { private final...
- golang 关于锁 mutex,踩过的坑
- <em>mutex</em>实例无需实例化，声明即可使用 func add(){ var <em>mutex</em> sync.Mutex <em>mutex</em>.Lock() defer <em>mutex</em>.Unlock() fmtPrintln(&amp;amp;amp;quot;test lock&amp;amp;amp;quot;) } <em>mutex</em>在传递给外部使用的时候，需要传指针,不然传的是拷贝，会引起锁失败。并且指针的<em>mutex</em>是一定要实例化过的。 func ad.
- C++——多线程编程（二）std::mutex 线程同步、解决资源竞争问题
- 前言线程同步这里的“同”不是同时、一起执行的意思，而是指协同、协助、互相配合。线程同步是指多个线程协同步调，按预定的先后次序进行运行。线程A和B一块配合，A执行到一定程度时要依靠B的某个结果，于是停下来，示意B运行；B依言执行，再将结果给A；A再继续操作。所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不返回，同时其它线程也不能调用这个方法。定义：即当有一个线程在对内存进行操作时，其
- 谁在死锁Mutex——用Windbg查找Mutex死锁所有者线程
- Who is blocking that Mutex? - Fun with WinDbg, CDB and KD 05 Aug 2006 By Ingo Rammer I'm currently toying with the idea of creating a small frontend to SOS.DLL (CDB/WinDb
- 关于互斥锁的死锁及解决措施
- <em>死锁</em>：1、什么是<em>死锁</em>： 一般情况下，如果同一个线程先后两次调用lock，在第二次调用时，由于锁已经被占用，该线程会挂起等待别的线程释放锁，然而锁正是被自己占用着的，该线程又被挂起而没有机会释放锁，因此就永远处于挂起等待状态了，这叫做<em>死锁</em>（Deadlock）。 另一种：若线程A获得了锁1，线程B获得了锁2，这时线程A调用lock试图获得锁2，结果是需要挂起等待线程B释放锁2，而这时线...
- C++11 thread 及互斥锁、条件变量
- 启动的格式： #include //包含头文件 void fucntion();//定义一个线程执行的函数 thread t1(fucntion);//线程启动这个函数 //一创建就自动运行，主线程非阻塞 void factorial(int n,char b,..);//带参数的函数，参数的个数顺延 thread t2(factorial,5,'a
- 基于C++11并发库的线程池与消息队列多线程框架——std::mutex类
- <em>mutex</em>类是可以用来保护共享数据的同步原语，防止被其他线程修改，也就是保证了该线程对共享数据的独占式访问。 简而言之，互斥是为了防止多线程同时访问共享资源而产生数据竞争，并提供多线程的同步支持。 <em>mutex</em> 提供了独占式的，非递归的所有权语义： 线程拥有互斥量的周期：从调用lock()或者是try_lock()开始，到调用unclock()为止； 当线程拥有互斥量后，所有其他的线程尝试...
- 互斥锁陷阱：优先级反转、死锁
- A higher priority task being delayed by a lower priority task in this manner is called ‘priority inversion’.
- C++ Boost 多线程(五)，线程的死锁
- #include &lt;iostream&gt; #include &lt;boost/thread.hpp&gt; using namespace std; boost::<em>mutex</em> <em>mutex</em>; void func1() { <em>mutex</em>.lock(); cout&lt;&lt;"call func1()..."&lt;&lt;endl; <em>mutex</em>.unlock(); } vo...
- muduo C++ 网络库——线程同步精要(1):互斥锁
- 互斥器：使用得最多的同步原语互斥锁的详细介绍在这一篇博文中：互斥锁 概念补充：RAII——资源的有效期与持有资源的对象的生命期严格绑定，即由对象的构造函数完成资源的分配(获取),同时由析构函数完成资源的释放。只要对象能正确地析构，就不会出现资源泄漏问题。 互斥器保护了临界区，任何一个时刻最多只能有一个线程在此<em>mutex</em>划出的临界区内活动。单独使用<em>mutex</em>时，主要为了保护共享数据。原则：-用RA...
- C++11 互斥锁
- 上一篇《C++<em>11</em> 并发指南二(std::thread 详解)》中主要讲到了 std::thread 的一些用法，并给出了两个小例子，本文将介绍 std::<em>mutex</em> 的用法。Mutex 又称互斥量，C++ <em>11</em>中与 Mutex 相关的类（包括锁类型）和函数都声明在 &lt;<em>mutex</em>&gt; 头文件中，所以如果你需要使用 std::<em>mutex</em>，就必须包含 &lt;<em>mutex</em>&gt; 头文件。&l...
- 用boost共享锁实现读写锁造成死锁问题
- 网上很容易找到一个用boost::shared_<em>mutex</em>来作为读写锁的例子： typedef boost::shared_<em>mutex</em> rw<em>mutex</em>; typedef boost::shared_lock readLock; typedef boost::unique_lock writeLock; 一直没有怀疑过这个做法，直到最近项目中出现一个<em>死锁</em>问题，查了很久才发现是上面这种
- 互斥锁与死锁
- 在多线程程序中，多个线程可能会共用同一个对象，为了防止多个线程在争夺、使用同一份对象时可能会对该对象造成的改变，引入互斥锁。互斥锁可保证在任一时刻，只能有一个线程访问该对象，从而保证共享数据操作的完整性。 互斥锁基本原理： 互斥锁是一个二元变量，其状态为开锁(允许0)和上锁(禁止1)，将某个共享资源与某个特定互斥锁在逻辑上绑定(要申请该资源必须先获取锁)。 (1)访问公共资源前，必须申请...
- linux线程同步之互斥锁mutex
- 互斥锁的意义和使用方法较为简单，有点类似于原子操作。先把常用的几个线程互斥锁相关的api列出，再一个个详细介绍：pthread_<em>mutex</em>_t <em>mutex</em> = PTHREAD_MUTEX_INITIALIZER;int pthread_<em>mutex</em>_init(pthread_<em>mutex</em>_t *restrict <em>mutex</em>, const pthread_<em>mutex</em>attr_t *restrict at...
- condition_variable的使用以及与锁的关系
- 条件变量和互斥锁是多线程的同步和互斥最基础的两种工具，其中互斥锁使用和功能都比较简单，条件变量在使用和理解起来相对就比较困难，不少初学者对于wait函数必须结合一个锁来使用的原则感到困惑，其实官方指导中已经有详尽的解释和案例，但讲的比较简洁，这里从wait函数执行流程来看下条件变量的使用方法和原理。 正确使用流程 thread1： locker.lock() ---1 cv.wait(...
- 可递归锁与非递归锁
- 可递归锁与非递归锁 概述 最常见的进程/线程的同步方法有互斥锁（或称互斥量Mutex)，读写锁(rdlock)，条件变量(cond)，信号量(Semophore)等。在Windows系统中，临界区（Critical Section）和事件对象(Event)也是常用的同步方法。 简单的说，互斥锁保护了一个临界区，在这个临界区中，一次最多只能进入一个线程。如果有多个进程在同
- 线程之互斥锁与死锁
- 互斥锁： 1、互斥锁基本原理： 互斥锁是一个二元变量，其状态为开锁(允许0)和上锁(禁止1)，将某个共享资源与某个特定互斥锁在逻辑上绑定(要申请该资源必须先获取锁)。 (1)访问公共资源前，必须申请该互斥锁，若处于开锁状态，则申请到锁对象，并立即占有该锁，以防止其他线程访问该资源；如果该互斥锁处于锁定状态，则阻塞当前线程。 (2)只有锁定该互斥锁的进程才能释放
- 在 C# 中，如何发现死锁并防止死锁
- 在解释<em>死锁</em>如何发生以及如何阻止<em>死锁</em>的过程中，你似乎遇到了问题。 当两个( 最小二) 线程试图获取已经被另一个锁锁定的资源的锁时，就会发生<em>死锁</em>。 线程 1锁定资源 1尝试获取对资源 2的锁定。 同时，线程 2对资源 2有一个锁，它尝试获取对资源 1的锁。 两个线程永远不会放弃锁，因此发生<em>死锁</em>。 避免<em>死锁</em>的最简单方法是使用超时值。 Monitor类( system.threading.monito...
- 一次Mutex死锁的原因探究
- 1、现象 最近项目中调出一个bug，某些时候程序会卡死不动，用windbg进行加载后用 ~*kb 命令列出所有的线程栈调用，发现有多个线程调用 WaitForMultipleObjects 在等待同一个内核对象：
- C++11多线程——lock详解
- C++<em>11</em>提供了两种管理锁的类 std::lock_guard：与<em>mutex</em> RAII相关，方便线程对互斥量上锁std::unique_lock: 与<em>mutex</em> RAII相关，方便线程对互斥量上锁，相比std::lock_guard提供了更好的上锁和解锁控制 一 lock_guard详解 lock_guard是一个模板类：templateclass lock_guar
- Java中线程同步锁和互斥锁有啥区别？看完你还是一脸懵逼？
- 首先不要钻概念牛角尖，这样没意义。 也许java语法层面包装成了sycnchronized或者明确的XXXLock，但是底层都是一样的。无非就是哪种写起来方便而已。 锁就是锁而已，避免多个线程对同一个共享的数据并发修改带来的数据混乱。 锁要解决的大概就只有这4个问题： "谁拿到了锁" 这个信息存哪里（可以是当前class，当前instance的markword，还可以是某个具体的Lock的...
- 虫趣：FAST_MUTEX死锁
- 问题到此可告一段落了： 线程1在处理IRP_MJ_POWER的时候，试图获取一个FAST_MUTEX同步对象，但因获取失败而进入休眠状态（并因休眠过久，而导致BSOD）。 在成功获取FAST_MUTEX对象的地址后，从它的结构体中得到了当前拥有此同步对象的线程2地址。 切换到线程2，发现线程2有一个无法处理的页错误，也同样处于等待状态中。
- c# 互斥锁（Mutex）使用详解
- http://zwkufo.blog.163.com/blog/static/258825120104297724292/ 互斥锁（Mutex） 互斥锁是一个互斥的同步对象，意味着同一时间有且仅有一个线程可以获取它。 互斥锁可适用于一个共享资源每次只能被一个线程访问的情况 函数： //创建一个处于未获取状态的互斥锁 Public Mutex（）； /
- 线程、同步与锁——Mutex想说爱你不容易
- 除了Lock（）、Monitor之外，我们最长用的就是Mutex了，但是玩不好Mutex就总会造成<em>死锁</em>或者AbandonedMutexException（我就玩的不怎么好，在并发性访问测试的时候总是遇到<em>关于</em>Mutex的问题，各位线虫见笑了，不过还是把我遇到的一些问题和总结拿出来和大家分享，有误的地方还往指正。 还是先举一个简单的例子，来说明一下这个东西： public c
- 死锁的产生以及避免原理和算法
- <em>死锁</em> 是指多个并发进程在运行过程中因竞争资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，这些进程都无法向前推进。并发性 ： 指两个或多个事件在同一时刻发生 并行性 ： 指两个或多个事件在同一时间间隔内发生 来看两种典型的<em>死锁</em>情形： 如果同⼀个线程先后两次调⽤lock,在第⼆次调⽤时,由于锁已经被占⽤,该线程会挂起等待别的线程释放锁,然⽽锁正是被⾃⼰占⽤着
- python中互斥锁与死锁的使用
- 在python中，多线程并发执行任务时，多个子线程有时候会争抢同一个主线程中的资源，导致程序报错，无法执行，这时，我们可以引入一个互斥锁的概念，使得一个资源在被一个子线程抓取到时候就不再被其他子线程抓取，直到第一个抓取到资源的子线程执行完程序，再释放出资源。 import threading # 全局变量 num = 0 # 任务一： def work1(number): # ...
- 死锁之动态锁顺序
- 1、由于方法入参由外部传递而来，方法内部虽然对两个参数按照固定顺序进行加锁，但是由于外部传递时顺序的不可控，而产生锁顺序造成的<em>死锁</em>，即动态锁顺序<em>死锁</em>。2、示例代码如下：// Warning: deadlock-prone! public static void transferMoney(Account fromAccount, A...
- pthread包的mutex实现分析
- pthread包 pthread是POSIX thread，一个在类UNIX系统下广泛使用的并发包，linux系统下在glibc库里实现。 pthread包里常用的<em>mutex</em>相关接口有： pthread_<em>mutex</em>_init pthread_<em>mutex</em>_lock pthread_<em>mutex</em>_trylock pthread_<em>mutex</em>_unlock pthread_<em>mutex</em>_dest...
- c++线程并发：mutex，atomic，自旋锁spinlock，单线程
- 自旋锁直接调用了boost库的#include 测试线程并发的情况下耗时，不太明白为什么boost的spinlock效率这么低，还是说boost的spinlock是有其它专业用途... 在一个共有资源的情况下， 由于任务的简单性，只是++，单线程最快 多线程无锁次之，但是结果错误 atomic原子操作耗时稍长，但由于原子操作的关系，结果正确 <em>mutex</em> 性能损失比较大，为at
- C++11 多线程2——Mutex的错误使用
- 本系列文章主要介绍C++<em>11</em> 中多线程的使用方法，主要参考书籍为《C++Concurrency IN Action》。 为了保证多线程访问数据的安全性，一种通常的做法是对需要保护的数据上锁，使用<em>mutex</em>保证互斥访问。可以使用的做法是调用lock()和unlock()函数，但是我们更加推荐使用模板类std::lock_guard，在该类的构造函数中完成lock()，而在析构函数中完成un
- C++11多线程之mutex等锁机制和atomic原子操作对比
- 一.简介这里以<em>mutex</em>锁机制为例. <em>mutex</em>函数:是一套专门用于线程同步锁机制的函数. #include using namespace std;atomic原子操作:是在新标准C++<em>11</em>，引入了原子操作的概念，并通过这个新的头文件提供了多种原子操作数据类型，例如，atomic_bool,atomic_int等等. #include
- 死锁之五个哲学家就餐问题 C语言实现
- #include&lt;stdio.h&gt;#include&lt;process.h&gt;#include&lt;windows.h&gt;#include&lt;stdlib.h&gt;#include&lt;math.h&gt;HANDLE Mutext[5];int chopstick = 0;int *Physical;unsigned int _stdcall ThreadFun(...
- 互斥量、读写锁长占时分析的利器——valgrind的DRD
- 在进行多线程编程时，我们可能会存在同时操作（读、写）同一份内存的可能性。为了保证数据的正确性，我们往往会使用互斥量、读写锁等同步方法。（转载请指明出于breaksoftware的csdn博客） 互斥量的用法如下 pthread_<em>mutex</em>_lock(&amp;<em>mutex</em>); // do something pthread_<em>mutex</em>_unlock(...
- 锁活跃性问题（死锁，饥饿、活锁）
- 一、<em>死锁</em> 每个人都拥有其他人需要的资源，同时又等待其他人已经拥有的资源，并且每个人在获取所有需要的资源之前都不会放弃已经拥有的资源。 当一个线程永远地持有一个锁，并且其他线程都尝试去获得这个锁时，那么它们将永远被阻塞，这个我们都知道。如果线程A持有锁L并且想获得锁M，线程B持有锁M并且想获得锁L，那么这两个线程将永远等待下去，这种情况就是最简单的<em>死锁</em>形式。其中多...
- 死锁原因及解决、避免办法
- <em>死锁</em>的条件 互斥条件(Mutual exclusion) ：资源不能被共享，只能由一个进程使用。 请求与保持条件(Hold and wait)：进程已获得了一些资源，但因请求其它资源被阻塞时，对已获得的资源保持不放。 不可抢占条件(No pre-emption) ：有些系统资源是不可抢占的，当某个进程已获得这种资源后，系统不能强行收回，只能由进程使
- 单线程中递归包含lock不会死锁
- 之前一直以为，lock当进入递归时，递归里面执行到lock (objectSyn)时会等待外层释放，而外层lock又会等待函数调用结束才释放。 后来看了《C#2.0 本质论》才知道lock只会生效于多线程，对于单线程，自身已经是锁的所有者，并不会出现为了继续加锁等待原有锁释放 另外在多线程里，公共对象被一个线程加锁后另一线程仍可对其进行操作
- gdb 查看死锁
- <em>死锁</em>：一种情形，此时执行程序中两个或多个线程发生永久堵塞（等待），每个线程都在等待被 其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了<em>死锁</em>现象。 gdb调试<em>死锁</em>的方法： gdb attach pid thread apply all bt 找到_lll_lo
- 因死锁发生的线程卡死
- 调试时，发现如果 收到的modbus数据写入到文件功能打开，另一个进程连续快速的调用msgsnd函数发送 会导致无功补偿App收不到数据，用ipcs-a 能看到内存中的有很多条消息， 关闭打印到文件功能函数， 通信就正常了。 在消息发送函数 msgsnd(msg_fd,&amp;gt_PipeMsg.rcvbuf[0], 13 ,IPC_NOWAIT)（发送线程中...
- atfork() --同步父子进程 pthread_mutex_lock加解锁问题
- 问题： 父进程先开启一个子线程，子线程中调用pthread_<em>mutex</em>_lock。再fork子进程，子进程同样调用pthread_<em>mutex</em>_lock ，导致的<em>死锁</em>问题。 sleep() 替换 nanosleep() 纳秒精度 //sleep(1); struct timespec ts = {1, 0}; nanos...
- c++多线程之死锁的发生的情况解析（包含两个归纳，6个示例）
- 一、<em>死锁</em>会在什么情况发生 1、假设有如下代码 <em>mutex</em>; //代表一个全局互斥对象 void A() { <em>mutex</em>.lock(); //这里操作共享数据 B(); //这里调用B方法 <em>mutex</em>.unlock(); return; } void B() { <em>mutex</em>.lock();
- 可重入锁和不可重入锁，递归锁和非递归锁
- 首先引入概念： 可重入锁：广义上的可重入锁指的是可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生<em>死锁</em>（前提得是同一个对象或者class），这样的锁就叫做可重入锁， java里面最常见的锁，ReentrantLock和synchronized都是可重入锁 不可重入锁：不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生<em>死锁</em>。即若当前线程执行某个方法已经获取了该锁，那么在方法...
- NtQueryObject遍历进程(死锁)与管道冲突的解决方案
- 在一次注入使用命名管道进行进程间通讯的案例中需要使用NtQueryObject遍历进程互斥锁情况，期间发现一个问题，NtQueryObject查询到管道时候会<em>死锁</em>，网上也有很多资料介绍NtQueryObject<em>死锁</em>的情况，不过解决方案不是很明确这里记录下解决办法在时候NtQueryObject打开进程关联句柄时，先使用CreateFileMapping假定创建文件句柄，如果创建成功，返回，当然假如...
- pthread_join 和pthread_detach的区别附加互斥锁代码实现
- 一个线程任何时候都可以被认为是可结合（joinable）或者是分离的（detached）。一个可结合的线程能够被其他线程收回其资源和杀死。在被其他线程回收之前，它的存储器资源（例如栈）是不释放的。相反，一个分离的线程是不能被其他线程回收或杀死的，它的存储器资源在它终止时由系统自动释放。 默认情况下，线程被创建成可结合的。为了避免存储器泄漏，每个可结合线程都应该要么被显示地回收，即调用pthr...
- RTOS一般锁保护使用与解决死锁问题
- RTOS有时候会因为用户的一句代码造成实时性或是性能降低，锁的正确使用更是能体现这一点。 一、RTOS一般锁使用情景： Semaphore：适用于较长代码的保护，或是任务之间、中断与任务之间的同步。如果该函数会引起任务阻塞，则不可以在中断中去获取信号量。 Mutex：适用于三个任务以上抢占的资源保护。因为<em>mutex</em>有优先级反转解决策略。 而semaphore一般都没有，所以它只适用于两个任务
- 自旋锁与互斥锁的对比、手工实现自旋锁
- 本文之前，我只是对自旋锁有所了解，知道它是做什么的，但是没有去测试实现过，甚至以为自旋锁只有kernel用这个，今天才发现POSIX有提供自旋锁的接口。下面我会分析一下自旋锁，并代码实现自旋锁和互斥锁的性能对比，以及利用C++<em>11</em>实现自旋锁。 一：自旋锁（spin lock） 自旋锁是一种用于保护多线程共享资源的锁，与一般互斥锁（<em>mutex</em>）不同之处在于当自旋锁尝试获取锁时以忙
- C++11多线程——mutex学习
- Mutex也称之为互斥量，C++<em>11</em>中与<em>mutex</em>相关的类与函数声明都在头文件中。 一头文件内容简介： Classes 1.1 Mutexes <em>mutex</em> <em>mutex</em>class(class) recursive_<em>mutex</em> Recursive<em>mutex</em> class(class) ti
- c++11多线程的创建和unique_lock的使用
- 1.多线程的创建（1）在cmakelist中加入编译选项c<em>11</em>和多线程 set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -Wall -std=c++<em>11</em> -pthread -g -march=native”) -g 表示debug（2）包括头文件 #include&lt;thread&gt; （3）新建线程 新建线程两个 使用thread 线程名来新建一个线程
- c++多线程 thread mutex 使用小结
- c++多线程 thread <em>mutex</em> 使用小结std::thread std::<em>mutex</em> 基本使用方法std::thread 用于开启一个线程。std::<em>mutex</em> 是互斥锁，防止不同线程间的代码在不同线程间做不安全的切换std::<em>mutex</em> try_lock()子线程作生产者、主线程做消费者子线程做加载、主线程显示百分比多线程里遇到的几个问题： c++对于多线程的支持，依赖于 std::th...
- Go 标准库 —— sync.Mutex 互斥锁
- Mutex 是一个互斥锁，可以创建为其他结构体的字段；零值为解锁状态。Mutex 类型的锁和线程无关，可以由不同的线程加锁和解锁。 方法 func (*Mutex) Lock func (m *Mutex) Lock() Lock 方法锁住 m，如果 m 已经加锁，则阻塞直到 m 解锁。 func (*Mutex) Unlock func (m *M...
- boost递归锁和非递归锁区别
- Mutex可以分为递归锁(recursive <em>mutex</em>)和非递归锁(non-recursive <em>mutex</em>)。可递归锁也可称为可重入锁(reentrant <em>mutex</em>)， 非递归锁又叫不可重入锁(non-reentrant <em>mutex</em>)。 二者唯一的区别是，同一个线程可以多次获取同一个递归锁，不会产生<em>死锁</em>。而如果一个线程多次获取同一个非递归锁，则会产生<em>死锁</em>。
- 递归锁（可重入锁）
- 近日在调试一个线程挂起的BUG，究其原因是该用递归锁的地方使用了普通的互斥锁，导致了<em>死锁</em>。 趁着这个机会也好好了解了一下很少用到的递归锁。 所谓递归锁，就是在同一线程上该锁是可重入的，对于不同线程则相当于普通的互斥锁。 例如：有互斥量LOCK func A （） { LOCK.lock(); B(); LOC
- 死锁原因排查
- 嘿，请检查一下有没有把pthread_<em>mutex</em>_unlock写成了pthread_<em>mutex</em>_lock。 用vim编辑器，写代码的时候yyp复制很方便，当你写了一行lock代码，yyp复制后本意是想unlock，无奈忘记把lock改为unlock。
- linux下记一次使用gdb对死锁问题的定位以及pthread_cancel使用的建议
- 程序跑死卡住了，怀疑是<em>死锁</em>引起的 使用 gdb attach pid 命令附加到那个进程上，然后再gdb里输入命令 info thread 得到如下信息 (gdb) info thread Id Target Id Frame 4 Thread 0x7f466b8e1700 (LWP 10945) "jtnvragentserve" 0x0000
- 线程与互斥锁（C++11中std::thread和std::mutex的用法）
- 线程 0 首先是曾经在MultiCMOS项目中用到的： #include &lt;thread&gt; //包含头文件 class IDataProcessUnit { protected: bool m_processing{ false }; //线程退出标识 std::thread m_thrProcess; //线程句柄 public: //数据处理流程在...
- UcosII 共享资源的锁机制的处理
- 使用Ucosii操作系统编写应用程序时，会经常使用到全局变量等共享资源。若在使用时，如对全局变量的同时的读写操作，可能会造成程序的崩溃，故在使用全局变量时，要对其进行锁或互斥处理。另，如果函数可以进行修改，则可通过函数的可重入性，即传形参使用局部变量，而避免使用全局变量。 共享资源处理简介： (1)关中断/开中断 关、开中断是独占共享资源最简单也是最快捷的方法。μC/OS
- 互斥信号量 pthread_mutex_t的使用
- 互斥信号量 pthread_<em>mutex</em>_t <em>mutex</em>
- 在vs中线程死锁时的一些调试经验
- 有时候因为一些操作导致线程<em>死锁</em> 了，也没有断点提示在哪里<em>死锁</em>，这时候可以点击“全部中断”按钮，如下图（类似暂停的那个按钮）：
- Linux--死锁产生条件及避免死锁算法
- 一．什么是<em>死锁</em>？ 所谓<em>死锁</em>是指在多道程序系统中，一组进程中的每一个进程均无限期的等待被该组进程中的另一个进程所占有且永远不会释放的资源，这种现象称系统处于<em>死锁</em>状态。 二．<em>死锁</em>产生的原因？ 1.竞争资源，系统产生的资源有限不能满足每个进程的需求。 2.多道程序运行时，进程推进顺序不合理。 三．形成<em>死锁</em>四个必要条件？ 1.互斥使用资源 2.请求和保持资源 3.不可抢夺资源
- 多线程之互斥锁（By C++)与多进程
- 多线程 锁 <em>死锁</em>
- C++11多线程互斥锁的使用
- #include #include #include #include #include #include #include // 参考：http://www.cnblogs.com/haippy/p/3284540.html namespace thread_lock { std::<em>mutex</em> g_io_<em>mutex</em>; //------------------------
- 关于Windows XP SP2 x86上不支持的两个C++11
- 这个年代了还有人用Windows XP SP2，我也是醉了。。。 这个bug估计很少有人遇到吧。 std::<em>mutex</em>和std::thread不支持在Windows XP SP2上运行，会报入下图的错误GetLogicalProcessorInformation找不到： 我是在visula studio 2015上面选择Visual Studio 2015 - Windows XP
- 同步锁、互锁（死锁）
- 经历了精心动魄的活动之后，对，锁、多线程的理解进一步加深了，记得在单例模式的时候接触过一点，但那都是皮毛，简单的理解。接下来和大家共同分享学习 java中cpu分给每个线程的时间片是随机的并且在java中好多都是多个线程共用一个资源，比如现在我们很多的抢火车卖票，火车票是一定的，但卖火车票的窗口到处都有，每个窗口就相当于一个线程，这么多的线程共用所有的火车票这个资源。如果在一个时间点上，两个线程
- 互斥锁vs共享锁vs自旋锁
- 共享锁：如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁，直到已释放所有共享锁。获准共享锁的事务只能读数据，不能修改数据。 排他锁：如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的锁，直到在事务的末尾将资源上的锁释放为止。获准排他锁的事务既能读数据，又能修改数据。 linux 自旋锁: 进程运行是会锁住自己所拥有的资源,不让其他进程来破坏(即自己锁住...
- Android多线程研究（3）——线程同步和互斥及死锁
- 为什么会有线程同步的概念呢？为什么要同步？什么是线程同步？先看一段代码：package com.maso.test; public class ThreadTest2 implements Runnable{ private TestObj testObj = new TestObj(); public static void main(String[] args) { Thread
- 使用gdb调试死锁线程
- 1.调试文件 lock.c #include #include #include void *work_thread(void *arg) { pthread_<em>mutex</em>_t <em>mutex</em>; pthread_<em>mutex</em>_init(&<em>mutex</em>, 0); usleep(1000*1000); fprintf(stderr, "timeout we will start dead lo
- RTOS的变量锁的发生
- 变量的改变有以下几个步骤，读-改-写，当一个变量被改变的时候，有任务或者中断将这个过程打断。同时在中断函数中，将变量重新赋值，那原来的变量改就失效，变量变成了我们不希望出现的值。因此我们需要在任务中屏蔽中断的发生。 下面我们将利用函数，模拟变量读改写的过程被打断： void task1Entry(void * param) { int i,j; i = 10; tSetSysTickPeriod(...
- 信号处理函数陷阱：调用malloc导致死锁
- <em>关于</em>信号处理signal()、sigaction()等的使用，相信很多人都已熟悉。 这里主要想讲一下信号处理函数使用上的一个常见陷阱：信号处理函数必须是可重入函数。如果信号处理函数不可重入，那么可能导致很多诡异问题。 《UNIX环境高级编程》“可重入函数”章节中这样写道： “但在信号处理程序中，不能判断捕捉到信号时进程在何处执行。如果进程正在执行mal
- 写一个死锁例子，及解决死锁
- package com.线程间通信;public class DeadLock {public static void main(String[] args) throws InterruptedException { final DeadLock dd1 = new DeadLock(); final DeadLock dd2 = new DeadLock(); Threa
- UNIX环境高级编程——线程同步之互斥锁、读写锁和条件变量（小结）
- 一、使用互斥锁1、初始化互斥量pthread_<em>mutex</em>_t <em>mutex</em> =PTHREAD_MUTEX_INITIALIZER;//静态初始化互斥量 int pthread_<em>mutex</em>_init(pthread_<em>mutex</em>_t*<em>mutex</em>,pthread_<em>mutex</em>attr_t*attr);//动态初始化互斥量 int pthread_<em>mutex</em>_destory(pthread_<em>mutex</em>_t*m
- 5线程同步-实现读写锁扩展C++11标准库
- 在C++<em>11</em>标准库中实现了线程的重要基本设施，使用这些功能轻松构建复杂的多线程程序，但是比起微软或者第三库功能还是不怎么全面，比如读写锁就没有实现，但是可以利用已有的功能，轻松实现一个读写锁。代码如下： #include #include #include using namespace std; class shared_<em>mutex</em> { private: /
- FreeRTOS 学习五：信号量和互斥锁
- 介绍freertos中的信号量
- c++11实现写优先的读写锁
- 先直接贴出代码： 可以看出用c++<em>11</em>实现读写锁变得非常简洁，在读取量非常大且写入频率很低的时候，通过一个简单的写入线程计数可以避免大量的 cond_w.notify_one();减少读取线程因此发生的切换。
- AutoLock 解决加锁后忘记解锁问题
- class AutoLock { public: AutoLock(CRITICAL_SECTION& cs) : cs_(cs) { EnterCriticalSection(&cs_); } ~AutoLock() { LeaveCriticalSection(&cs_); } private: CRITICAL_SECTION& cs_; }; class Test { public: Test() { InitializeCriti
- linux死锁检测与调试
- linux<em>死锁</em>检测与调试 什么是<em>死锁</em> D 状态<em>死锁</em>和 R 状态<em>死锁</em> soft lockup 和 hard lockup linux内核<em>死锁</em>如何调试 相关内核配置选项 Linux检测<em>死锁</em>实现分析 soft lockup检测原理 hard lockup检测原理 常见<em>死锁</em>错误 如何避免<em>死锁</em> 参考资料linux<em>死锁</em>检测与调试什么是<em>死锁</em>？ <em>死锁</em>是指多个进程（线程）因为长久等待已被其他进程占有的的资源而陷入阻
- 多线程编程的锁问题解析（锁竞争死锁活锁及Date Race等）
- 为了防止例1中的数据竞跑现象，我们可以使用锁来保证每个线程对counter++操作的独占访问（即保证该操作是原子的）。在例3的程序中，我们使用<em>mutex</em>锁将counter++操作放入临界区中，这样同一时刻只有获取锁的线程能访问该临界区，保证了counter++的原子性：即只有在线程1执行完counter++的三条指令之后线程2才能执行counter++操作，保证了counter的最终值必定为2。
- 互斥锁的应用与pthread_mutex_destory的出错
- 一、互斥锁的应用 互斥量从本质上说就是一把锁, 提供对共享资源的保护访问。 1. 初始化: 在Linux下, 线程的互斥量数据类型是pthread_<em>mutex</em>_t. 在使用前, 要对它进行初始化: 对于静态分配的互斥量, 可以把它设置为PTHREAD_MUTEX_INITIALIZER. 对于动态分配的互斥量, 在申请内存(malloc)之后, 通过pthread_<em>mutex</em>
- 关于 windows 互斥锁CRITICAL_SECTION 多次加锁，需要多少释放的问题
- 我们程序里，有时某个线程会对锁，连续加两次锁，我以前以为只要释放一次，就会释放该临界区，可不是这样的。应该几次加锁，就应该几次释放锁。 CRITICAL_SECTION mylock; DWORD WINAPI ThreadFunc3(LPVOID lpParameter) { EnterCriticalSection(&mylock); cout EnterCrit
- 线程同步之信号量（sem_init,sem_post,sem_wait）
- 信号量和互斥锁(<em>mutex</em>)的区别：互斥锁只允许一个线程进入临界区，而信号量允许多个线程同时进入临界区。 不多做解释，要使用信号量同步，需要包含头文件semaphore.h。 主要用到的函数： int sem_init(sem_t *sem, int pshared, unsigned int value);，其中sem是要初始化的信号量，pshared表示此信号量是在进程间
- 键盘记录源代码下载
- 键盘记录源码，好东西，不可多的 相关下载链接：[url=//download.csdn.net/download/liuchenglei/339504?utm_source=bbsseo]//download.csdn.net/download/liuchenglei/339504?utm_source=bbsseo[/url]
- 《大象 Thinking In UML》pdf版（带书签）卷1/3下载
- 1、09年度畅销榜NO.3 2、这是一本令众多开发网友企盼了一年之久的书. 这是一本讲分析、设计、建模与统一软件过程的书 这是一本将晦涩的概念与项目的实践紧密结合的书.. 这是一本充满思想和智慧的书 这不是一本一般的书... 3、本书以UML为载体，将面向对象的分析设计思想巧妙地融入建模过程中，通过贯穿全书的实例将软件系统开发过程中方方面面的知识有机地结合在一起，用生动的语言和精彩的事例将复杂枯燥的软件过程讲解得津津有味。 全书分为准备篇、基础篇、进阶篇和总结篇四个部分。准备篇讲述面向对象分析的一些基本概念，及学习建模需要了解的一些基本知识。基础篇对UML的基础概念重新组织和归纳整理，进行扩 相关下载链接：[url=//download.csdn.net/download/mmmbaby/2091566?utm_source=bbsseo]//download.csdn.net/download/mmmbaby/2091566?utm_source=bbsseo[/url]
- android进程间通信之AIDL下载
- android进程间通信之AIDL的简单的示例代码 相关下载链接：[url=//download.csdn.net/download/Niosm/3593187?utm_source=bbsseo]//download.csdn.net/download/Niosm/3593187?utm_source=bbsseo[/url]
我们是很有底线的