我们先通过一个简单的代码来了解该问题。
同步问题
我们使用一个简单的结构体 Counter,该结构体包含一个值以及一个方法用来改变这个值:
struct Counter { int value; void increment(){ ++value; } };
然后启动多个线程来修改结构体的值:
int main(){ Counter counter; std::vector<std::thread> threads; for(int i = 0; i < 5; ++i){ threads.push_back(std::thread([&counter](){ for(int i = 0; i < 100; ++i){ counter.increment(); } })); } for(auto& thread : threads){ thread.join(); } std::cout << counter.value << std::endl; return 0; }
我们启动了5个线程来增加计数器的值,每个线程增加了100次,然后在线程结束时打印计数器的值。
但我们运行这个程序的时候,我们是希望它会答应500,但事实不是如此,没人能确切知道程序将打印什么结果,下面是在我机器上运行后打印的数据,而且每次都不同:
442 500 477 400 422 487
问题的原因在于改变计数器值并不是一个原子操作,需要经过下面三个操作才能完成一次计数器的增加:
但你使用单线程来运行这个程序的时候当然没有任何问题,因此程序是顺序执行的,但在多线程环境中就有麻烦了,想象下下面这个执行顺序:
这种情况我们称之为多线程的交错执行,也就是说多线程可能在同一个时间点执行相同的语句,尽管只有两个线程,交错的现象也很明显。如果你有更多的线程、更多的操作需要执行,那么这个交错是必然发生的。
有很多方法来解决线程交错的问题:
在这篇文章中我们将学习如何使用信号量来解决这个问题。信号量也有很多人称之为互斥量(Mutex),同一个时间只允许一个线程获取一个互斥对象的锁,通过 Mutex 的简单属性就可以用来解决交错的问题。
使用 Mutex 让计数器程序是线程安全的
在 C++11 线程库中,互斥量包含在 mutex 头文件中,对应的类是 std::mutex,有两个重要的方法 mutex:lock() 和 unlock() ,从名字上可得知是用来锁对象以及释放锁对象。一旦某个互斥量被锁,那么再次调用 lock() 返回堵塞值得该对象被释放。
为了让我们刚才的计数器结构体是线程安全的,我们添加一个 set:mutext 成员,并在每个方法中通过 lock()/unlock() 方法来进行保护:
struct Counter { std::mutex mutex; int value; Counter() : value(0) {} void increment(){ mutex.lock(); ++value; mutex.unlock(); } };
然后我们再次测试这个程序,打印的结果就是 500 了,而且每次都一样。
异常和锁
现在让我们来看另外一种情况,想象我们的的计数器有一个减操作,并在值为0的时候抛出异常:
struct Counter { int value; Counter() : value(0) {} void increment(){ ++value; } void decrement(){ if(value == 0){ throw "Value cannot be less than 0"; } --value; } };
然后我们不需要修改类来访问这个结构体,我们创建一个封装器:
struct ConcurrentCounter { std::mutex mutex; Counter counter; void increment(){ mutex.lock(); counter.increment(); mutex.unlock(); } void decrement(){ mutex.lock(); counter.decrement(); mutex.unlock(); } };
大部分时候该封装器运行挺好,但是使用 decrement 方法的时候就会有异常发生。这是一个大问题,一旦异常发生后,unlock 方法就没被调用,导致互斥量一直被占用,然后整个程序就一直处于堵塞状态(死锁),为了解决这个问题我们需要用 try/catch 结构来处理异常情况:
void decrement(){ mutex.lock(); try { counter.decrement(); } catch (std::string e){ mutex.unlock(); throw e; } mutex.unlock(); }
这个代码并不难,但看起来很丑,如果你一个函数有 10 个退出点,你就必须为每个退出点调用一次 unlock 方法,或许你可能在某个地方忘掉了 unlock ,那么各种悲剧即将发生,悲剧发生将直接导致程序死锁。
接下来我们看如何解决这个问题。
自动锁管理
当你需要包含整段的代码(在我们这里是一个方法,也可能是一个循环体或者其他的控制结构),有这么一种好的解决方法可以避免忘记释放锁,那就是 std::lock_guard.
这个类是一个简单的智能锁管理器,但创建 std::lock_guard 时,会自动调用互斥量对象的 lock() 方法,当 lock_guard 析构时会自动释放锁,请看下面代码:
struct ConcurrentSafeCounter { std::mutex mutex; Counter counter; void increment(){ std::lock_guard<std::mutex> guard(mutex); counter.increment(); } void decrement(){ std::lock_guard<std::mutex> guar(mutex); mutex.unlock(); } };
是不是看起来爽多了?
使用 lock_guard ,你不再需要考虑什么时候要释放锁,这个工作已经由 std::lock_guard 实例帮你完成。
结论
在这篇文章中我们学习了如何通过信号量/互斥量来保护共享数据。需要记住的是,使用锁会降低程序性能。在一些高并发的应用环境中有其他更好的解决办法,不过这不在本文的讨论范畴之内。
你可以在 Github 上获取本文的源码.
互斥量是最通用的机制,但其并非保护共享数据的唯一方式。这里有很多替代方式可以在特定情况下,提供更加合适的保护。 一个特别极端(但十分常见)的情况就是,共享数据在并发访问和初始化时(都需要保护),但是之后需要进行隐式同步。这可能是因为数据作为只读方式创建,所以没有同步问题;或者因为必要的保护作为对数据操作的一部分,所以隐式的执行。任何情况下,数据初始化后锁住一个互斥量,纯粹是为了保护其初始化过程(这
当程序中有共享数据,肯定不想让其陷入条件竞争,或是不变量被破坏。那么,将所有访问共享数据结构的代码都标记为互斥岂不是更好?这样任何一个线程在执行这些代码时,其他任何线程试图访问共享数据结构,就必须等到那一段代码执行结束。于是,一个线程就不可能会看到被破坏的不变量,除非它本身就是修改共享数据的线程。 当访问共享数据前,使用互斥量将相关数据锁住,再当访问结束后,再将数据解锁。线程库需要保证,当一个线程
本文向大家介绍C++进程间共享数据实例,包括了C++进程间共享数据实例的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了C++进程间共享数据的实现方法,分享给大家供大家参考。具体实现方法如下: 希望本文所述对大家的C++程序设计有所帮助。
本文向大家介绍深入探究Java多线程并发编程的要点,包括了深入探究Java多线程并发编程的要点的使用技巧和注意事项,需要的朋友参考一下 关键字synchronized synchronized关键可以修饰函数、函数内语句。无论它加上方法还是对象上,它取得的锁都是对象,而不是把一段代码或是函数当作锁。 1,当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块
本文向大家介绍Lua中的协同程序探究,包括了Lua中的协同程序探究的使用技巧和注意事项,需要的朋友参考一下 哎,周五晚上我都还这么努力看书,真是好孩子。(小若:不想吐槽了) 其实我都准备玩游戏看电影去的了,但是这书就摆在桌子上,而且正对着我,就想着,扫两眼吧。 结果一扫就不对劲了,因为这内容有点绕,有点小混乱,如果我现在不记录下来的话,下周一可能又要重新看一次了。 好吧,今天我们来聊聊协同程序
为啥最后打印类似100475,100425之类的值? 我看写这个的人说会打印200000.
由于进程数据隔离,A进程的数据无法直接的被B使用,为解决该问题,可以尝试使用Swoole自带的Memory模块。 或者也可以尝试使用EasySwoole提供的ShareMemory,或者借助第三方的类似Redis之类的服务。
主要内容:应用程序类数据共享的过程当 JVM 启动时,它会将类加载到内存中作为初步步骤。如果有多个具有多个类的 jar,则第一个请求会出现明显的滞后。在无服务器架构中,这种延迟会延迟启动时间,这是此类架构中的关键操作。应用程序类数据共享概念有助于减少应用程序的启动时间。Java 具有现有的 CDS(类数据共享)功能。通过应用程序类数据共享,Java 10 允许将应用程序类放在共享存档中。这通过跨多个 Java 进程共享公共类元数据