网站做seo的好处,wordpress 启用多站点,免费版多用户商城源码,wordpress 滑动解锁目录
一、线程间共享数据
1.数据共享和条件竞争
2.避免恶性条件竞争 二、用互斥量来保护共享数据
1. 互斥量机制
2.mutex头文件介绍
三、C中使用互斥量mutex
1. 互斥量mutex使用 2.mutex类成员函数
① 构造函数
② lock()
③ unlock()
④ try_lock()
四、使用std::…目录
一、线程间共享数据
1.数据共享和条件竞争
2.避免恶性条件竞争 二、用互斥量来保护共享数据
1. 互斥量机制
2.mutex头文件介绍
三、C中使用互斥量mutex
1. 互斥量mutex使用 2.mutex类成员函数
① 构造函数
② lock()
③ unlock()
④ try_lock()
四、使用std::lock_guard
五、使用std::unique_lock
六、接口间的条件竞争
七、死锁问题 一、线程间共享数据
1.数据共享和条件竞争
如果共享数据是只读的那么所有线程都会获得相同的数据因为不会涉及对数据的修改。但是当一个线程或多个线程去修改共享数据时需要考虑到共享数据的一致性问题。
当一个线程对共享数据进行修改的同时有其他线程对该共享数据进行读取或修改操作可能得到的并不是期望的结果这是常见的错误条件竞争。
并发中竞争条件的形成取决于一个以上线程的相对执行顺序每个线程都抢着完成自己的任务。大多数情况下即使改变执行顺序也是良心竞争其结果可以接受。例如有两个线程同时执行读取任务只要完成相应读取任务就可以了谁先谁后这时的竞争是没有影响的。
恶性条件竞争通常发生于完成对多余一个的数据块的修改时。 2.避免恶性条件竞争
①对数据结构采用某种保护机制确保只有进行修改的线程才能看到不变量被破坏时的中间状态。从其他访问线程的角度来看修改不是已经完成了就是还没开始。例如线程A对变量a0进行10操作线程B读到了A线程中a10a已经改变但是A的线程最后把a重新-10实际对a没有修改。线程B访问到线程A的变量的中间状态
②对数据结构和不变量的设计进行修改修改完的结构必须能完成一系列不可分割的变化也就是保证每个不变量保持稳定的状态这就是所谓的无锁编程。
③使用事务的方式去处理数据结构的更新。所需的一些数据和读取都存储在事务日志中然后将之前的操作合为一步再进行提交。当数据结构被另一个线程修改后或处理已经重启的情况下提交就会无法进行这称作为“软件事务内存”(software transactional memory (STM))。例如线程A对变量a的前后两次修改修改合成一步当成事务提交线程B访问时就只能看到a最后的修改状态 二、用互斥量来保护共享数据
1. 互斥量机制
当访问共享数据前将数据锁住在访问结束后再将数据解锁。线程库需要保证当一个线程使用特定互斥量锁住共享数据时其他的线程想要访问锁住的数据都必须等到之前的线程对数据解锁后才能进行访问。这就保证了所有线程都能看到共享数据并不破坏不变量。
2.mutex头文件介绍
C 11中与 mutex 相关的类包括锁类型和函数都声明在 mutex 头文件中所以如果你需要使用 std::mutex就必须包含 mutex 头文件。
Mutex 系列类(四种)
std::mutex最基本的 Mutex 类。std::recursive_mutex递归 Mutex 类。std::time_mutex定时 Mutex 类。std::recursive_timed_mutex定时递归 Mutex 类。
Lock 类两种
std::lock_guard与 Mutex RAII 相关方便线程对互斥量上锁。std::unique_lock与 Mutex RAII 相关方便线程对互斥量上锁但提供了更好的上锁和解锁控制。
其他类型
std::once_flagstd::adopt_lock_tstd::defer_lock_tstd::try_to_lock_t
函数
std::try_lock尝试同时对多个互斥量上锁。std::lock可以同时对多个互斥量上锁。std::call_once如果多个线程需要同时调用某个函数call_once 可以保证多个线程对该函数只调用一次。 三、C中使用互斥量mutex
1. 互斥量mutex使用
C中通过实例化 std::mutex 创建互斥量实例通过成员函数 lock()对互斥量上锁unlock()进行解锁。实践中不推荐直接调用成员函数调用成员函数意味着必须在每个函数出口去调用unlock(),也包括异常的情况。
#include iostream
#include thread
#include mutexusing namespace std;class Test
{
private:std::mutex tmutex;
public:void add(int num) {tmutex.lock();//上锁num;cout num endl;tmutex.unlock();//解锁}
};int main()
{int num 100;Test t;std::thread thread01(Test::add,t, std::ref(num));std::thread thread02(Test::add,t, std::ref(num));thread01.join();thread02.join();
} 2.mutex类成员函数 ① 构造函数 作用构造一个互斥量对象。该对象处于未锁定状态。 互斥对象不能被复制/移动(该类型的拷贝构造函数和赋值操作符都被删除)。
② lock()
作用互斥量上锁。 线程调用该函数会发生下面 3 种情况 1如果互斥锁当前没有被任何线程锁定则调用线程将其锁定(从此时开始直到调用其成员unlock该线程拥有互斥锁)。 2如果互斥锁当前被另一个线程锁定则调用线程的执行将被阻塞直到被另一个线程解锁(其他未锁定的线程继续执行)。 3如果互斥锁当前被调用该函数的同一个线程锁定则会产生死锁(带有未定义的行为)。 ③ unlock()
作用互斥量解锁释放互斥量的所有权。 如果其他线程在试图锁定同一个互斥量时被阻塞其中一个线程将获得该互斥锁的所有权并继续执行。 互斥量的所有上锁和解锁操作都遵循单一的总顺序对同一对象的上锁操作和解锁操作之间是同步的。 如果互斥锁当前未被调用线程锁定则会导致未定义的行为。 ④ try_lock()
作用尝试锁住互斥量如果互斥量被其他线程占有则当前线程也不会被阻塞。 线程调用该函数也会出现3 种情况 1如果互斥量当前没有被任何线程锁定则调用线程将其锁定(从此时开始直到调用其成员unlock该线程拥有互斥锁)。 2如果互斥锁当前被另一个线程锁定则函数失败并返回false但不会阻塞(调用线程继续执行)。 3如果互斥锁当前被调用该函数的同一个线程锁定则会产生死锁(带有未定义的行为)。 四、使用std::lock_guard
C标准库为互斥量提供了一个RAII语法的模板类 std::lock_guard它通过让互斥对象始终处于锁定状态来管理它的对象。
在构造时互斥对象被调用线程锁定在析构销毁时互斥对象被解锁。它是特别适用于具有自动持续时间直到其上下文结束的对象。通过这种方式它保证在抛出异常时正确解锁互斥对象。
但是请注意lock_guard对象并不以任何方式管理互斥对象的生命周期:互斥对象的持续时间应该至少延长到锁定它的lock_guard被销毁为止。
#include iostream
#include thread
#include mutexusing namespace std;class Test
{
private:std::mutex tmutex;
public:void add(int num) {lock_guardstd::mutex guard(tmutex);//构造时上锁num;cout num endl;}//析构时解锁
};int main()
{int num 100;Test t;std::thread thread01(Test::add,t, std::ref(num));std::thread thread02(Test::add,t, std::ref(num));thread01.join();thread02.join();
}
定义lock_guard的时候调用构造函数加锁大括号结束调用析构函数解锁。
【注意】在使用互斥量来保护数据时要注意检查指针和引用。切勿将受保护数据的指针或引用传递到互斥锁作用域之外无论是函数返回值还是存储在外部可见内存亦或是以参数的形式传递到用户提供的函数中去。只要没有成员函数通过返回值或者输出参数的形式向其调用者返回指向受保护数据的指针或引用数据就是安全的。
缺陷在定义lock_guard的地方会调用构造函数加锁在离开定义域的话lock_guard就会被销毁调用析构函数解锁。这就产生了一个问题如果这个定义域范围很大的话那么锁的粒度就很大很大程序上会影响效率。
所以为了解决lock_guard锁的粒度过大的原因unique_lock就出现了。 五、使用std::unique_lock
unique_lock会在这个构造函数加锁然后可以利用unique.unlock()来解锁所以当你觉得锁的粒度太多的时候可以利用这个来中途解锁而析构的时候会判断当前锁的状态来决定是否解锁如果当前状态已经是解锁状态了那么就不会再次解锁而如果当前状态是加锁状态就会自动调用unique.unlock()来解锁。而lock_guard在析构的时候一定会解锁也没有中途解锁的功能。
方便肯定是有代价的unique_lock内部会维护一个锁的状态所以在效率上肯定会比lock_guard慢。 unique_lock是管理的互斥对象在锁定和解锁两种状态下都具有唯一的所有权。 在构造(或通过对其移动赋值)时对象获得一个互斥对象对其锁定和解锁操作。 这个类保证销毁时的状态为解锁(即使没有显式调用)。因此它作为具有自动持续时间的对象特别有用因为它保证在抛出异常时正确解锁互斥对象。 请注意unique_lock对象并不以任何方式管理互斥对象的生命周期:互斥对象的持续时间至少应该延长到管理它的unique_lock被销毁为止。 #include iostream // std::cout
#include thread // std::thread
#include mutex // std::mutex, std::unique_lockvoid print_block (int n, char c) {std::unique_lockstd::mutex lck (mtx);for (int i0; in; i) {std::cout c;}std::cout \n;
}int main ()
{std::thread th1 (print_block,50,*);std::thread th2 (print_block,50,$);th1.join();th2.join();return 0;
} 六、接口间的条件竞争
因为使用了互斥量或其他机制保护了共享数据就不必再为条件竞争所担忧吗
并不是你依旧需要确定数据是否受到了保护。例如
构建一个类似于std::stack结构的栈除了构造函数和swap()以外需要对std::stack提供五个操作push()一个新元素进栈pop()一个元素出栈top()查看栈顶元素empty()判断栈是否是空栈size()了解栈中有多少个元素。即使修改了top()使其返回一个拷贝而非引用对内部数据使用一个互斥量进行保护不过这个接口仍存在条件竞争。这个问题不仅存在于基于互斥量实现的接口中在无锁实现的接口中条件竞争依旧会产生。这是接口的问题与其实现方式无关。 七、死锁问题
死锁是指多个进程循环等待彼此占有的资源而无限期的僵持等待下去的局面。一对线程需要对他们所有的互斥量做一些操作其中每个线程都有一个互斥量且等待另一个解锁。这样没有线程能工作因为他们都在等待对方释放互斥量。这种情况就是死锁它的最大问题就是由两个或两个以上的互斥量来锁定一个操作。 死锁产生的四个条件 互斥性线程对资源的占有是排他性的一个资源只能被一个线程占有直到释放。请求和保持条件一个线程对请求被占有资源发生阻塞时对已经获得的资源不释放。非抢占一个线程在释放资源之前其他的线程无法剥夺占用。循环等待发生死锁时线程进入死循环永久阻塞。 避免死锁的方法
1避免嵌套锁
一个线程已获得一个锁时再别去获取第二个。因为每个线程只持有一个锁锁上就不会产生死锁。即使互斥锁造成死锁的最常见原因也可能会在其他方面受到死锁的困扰(比如线程间的互相等待)。当你需要获取多个锁使用一个std::lock来做这件事(对获取锁的操作上锁)避免产生死锁。
待完善
