多线程同步:使用 std::mutex 和 std::unique_lock 保护共享资源

2024-04-18 02:52

本文主要是介绍多线程同步:使用 std::mutex 和 std::unique_lock 保护共享资源,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在当今的软件开发中,多线程编程是一项至关重要的技术,它允许程序同时执行多个任务,从而提高应用程序的效率和响应速度。然而,多线程环境也带来了数据安全和一致性的挑战。在多个线程需要访问和修改同一数据资源的情况下,如果没有适当的同步机制,就可能发生竞态条件,导致数据不一致或程序行为的不确定性。为了解决这些问题,锁的概念应运而生。

锁是一种用于管理对共享资源访问的同步机制,主要用于多线程环境中保护共享资源,防止多个线程同时访问同一资源通过锁定机制,可以确保在任意时刻,只有一个线程可以访问关键的代码区域,从而维护了数据的完整性和一致性。常见的锁机制包括互斥锁(mutex)、读写锁(允许多个读操作同时进行,但写操作是独占的)和递归锁等。

 

基本概念

  • std::thread: C++标准库中的线程类,用于创建和管理线程。
  • std::mutex: 用于保护共享数据,防止多个线程同时访问同一资源。
  • std::unique_lock: 是一个RAII(资源获取即初始化)风格的mutex管理工具。它可以在构造时自动锁定关联的mutex,并在析构时自动释放mutex。

例子

目标:创建两个线程,共同操作一个共享的计数器(int类型),每个线程增加10000次计数器,使用std::mutex来同步对计数器的访问。

不使用锁的情况示例代码

首先,让我们看看在不使用互斥锁的情况下,多线程访问共享资源可能导致的问题。

#include <iostream>
#include <thread>// 共享资源
int counter = 0;void incrementCounter() {for (int i = 0; i < 10000; ++i) {++counter;  // 直接修改共享资源,没有锁的保护}
}int main() {std::thread t1(incrementCounter);std::thread t2(incrementCounter);t1.join();t2.join();std::cout << "Final counter value without mutex: " << counter << std::endl;return 0;
}

可能的输出

Final counter value without mutex: 13542

在这个示例中,因为两个线程都在尝试修改同一个变量而没有同步措施,所以最终的counter值并不是预期的20000,而是一个随机的值,这是因为发生了竞态条件。

使用锁的情况示例代码

现在,我们使用std::mutexstd::unique_lock来同步对共享资源的访问。

#include <iostream>
#include <thread>
#include <mutex>// 共享资源
int counter = 0;
std::mutex mtx;void incrementCounter() {for (int i = 0; i < 10000; ++i) {std::unique_lock<std::mutex> lock(mtx);  // 使用unique_lock来锁定mtx++counter;}
}int main() {std::thread t1(incrementCounter);std::thread t2(incrementCounter);t1.join();t2.join();std::cout << "Final counter value with mutex: " << counter << std::endl;return 0;
}

结果

Final counter value with mutex: 20000

在这个版本的代码中,每次修改共享资源counter时都通过std::unique_lock来确保只有一个线程可以执行这一操作。结果显示,最终的counter值正是预期的20000,说明通过锁正确地管理了线程间的资源访问。

为何不涉及变量 i

关于循环变量 i,它是每个线程的局部变量,而不是共享资源。每个线程在调用 incrementCounter 函数时都会有自己的 i 副本。因此,不需要通过互斥锁来保护对 i 的访问,因为不存在多个线程同时访问或修改同一个 i 的问题。

在多线程环境中,通常只有对共享资源的访问和修改才需要同步机制(如互斥锁)。局部变量自然地由各自的线程独立管理,不会引起线程间的冲突。

总结

在C++多线程编程中,std::mutexstd::unique_lock是保护共享数据和避免竞态条件的重要工具。通过使用std::unique_lock,可以更安全和便捷地管理锁的获取和释放,从而简化代码并减少因错误管理锁而导致的问题。

这篇关于多线程同步:使用 std::mutex 和 std::unique_lock 保护共享资源的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/913584

相关文章

Pandas使用SQLite3实战

《Pandas使用SQLite3实战》本文主要介绍了Pandas使用SQLite3实战,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学... 目录1 环境准备2 从 SQLite3VlfrWQzgt 读取数据到 DataFrame基础用法:读

JSON Web Token在登陆中的使用过程

《JSONWebToken在登陆中的使用过程》:本文主要介绍JSONWebToken在登陆中的使用过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录JWT 介绍微服务架构中的 JWT 使用结合微服务网关的 JWT 验证1. 用户登录,生成 JWT2. 自定义过滤

Java中StopWatch的使用示例详解

《Java中StopWatch的使用示例详解》stopWatch是org.springframework.util包下的一个工具类,使用它可直观的输出代码执行耗时,以及执行时间百分比,这篇文章主要介绍... 目录stopWatch 是org.springframework.util 包下的一个工具类,使用它

Java使用Curator进行ZooKeeper操作的详细教程

《Java使用Curator进行ZooKeeper操作的详细教程》ApacheCurator是一个基于ZooKeeper的Java客户端库,它极大地简化了使用ZooKeeper的开发工作,在分布式系统... 目录1、简述2、核心功能2.1 CuratorFramework2.2 Recipes3、示例实践3

springboot security使用jwt认证方式

《springbootsecurity使用jwt认证方式》:本文主要介绍springbootsecurity使用jwt认证方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地... 目录前言代码示例依赖定义mapper定义用户信息的实体beansecurity相关的类提供登录接口测试提供一

go中空接口的具体使用

《go中空接口的具体使用》空接口是一种特殊的接口类型,它不包含任何方法,本文主要介绍了go中空接口的具体使用,具有一定的参考价值,感兴趣的可以了解一下... 目录接口-空接口1. 什么是空接口?2. 如何使用空接口?第一,第二,第三,3. 空接口几个要注意的坑坑1:坑2:坑3:接口-空接口1. 什么是空接

springboot security快速使用示例详解

《springbootsecurity快速使用示例详解》:本文主要介绍springbootsecurity快速使用示例,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录创www.chinasem.cn建spring boot项目生成脚手架配置依赖接口示例代码项目结构启用s

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

java中使用POI生成Excel并导出过程

《java中使用POI生成Excel并导出过程》:本文主要介绍java中使用POI生成Excel并导出过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录需求说明及实现方式需求完成通用代码版本1版本2结果展示type参数为atype参数为b总结注:本文章中代码均为

Spring Boot3虚拟线程的使用步骤详解

《SpringBoot3虚拟线程的使用步骤详解》虚拟线程是Java19中引入的一个新特性,旨在通过简化线程管理来提升应用程序的并发性能,:本文主要介绍SpringBoot3虚拟线程的使用步骤,... 目录问题根源分析解决方案验证验证实验实验1:未启用keep-alive实验2:启用keep-alive扩展建