锁是一个常见的同步概念，我们都听说过加锁（lock）或者解锁（unlock），当然学术一点的说法是获取（acquire）和释放（release）。
注：互斥关系保证的是数据的访问正常，而同步关系是为了让多线程（生产和消费者）之间协同起来
管道一般为有亲缘关系进程提供单路数据流， 通过pipe（int fd[2]）创建， 返回两个文件描述符, fd[0] 用于读，fd[1]用于写。 通过 read 和 write 函数进行 操作。
锁是高性能程序的杀手，但是为了保证数据的一致性，在多线程的应用环境下又不得不加锁。但是在某些特殊的场景下， 是可以通过优化数据结构来达到无锁的目的。那么我们就来看一下如何实现一个无锁队列。 队列：众所周知，就是先进先出。 出队列的时候从队列头取出一个结点；入队列的时候，将结点添加到队列尾部。当多线程同时操作一个队列读写时，显然就需要加锁。但是在单读单写的这种多线程应用时，是可以做到无锁的。直接上代码 #ifndef _QUEUE_H_ #define _QUEUE_H_ template<class T>
不是什么时候都要靠上锁的。从根源出发，我们为什么需要上锁？因为线程在使用资源的过程中可能会出现冲突，对于这种会出现冲突的资源，还是锁住轮着用比较好。
对于任务队列，可以由多个线程进行访问，我们就需要加锁保护了，把之前写过的锁的小组件引入进来：
1. 在先前我们的生产消费模型代码中，一个线程如果想要操作临界资源，也就是对临界资源做修改的时候，必须临界资源是满足条件的才能修改，否则是无法做出修改的，比如下面的push接口，当队列满的时候，此时我们称临界资源条件不就绪，无法继续push，那么线程就应该去cond的队列中进行wait，如果此时队列没满，也就是临界资源条件就绪了，那么就可以继续push，调用_q的push接口。 但是通过代码你可以看到，如果我们想要判断临界资源是否就绪，是不是必须先加锁然后再判断？因为本身判断临界资源，其实就是在访问临界资源，既然要访问临界资源，你需不需要加锁呢？当然是需要的！因为临界资源需要被保护！ 所以我们的代码就呈现下面这种样子，由于我们无法事前得知临界资源的状态是否就绪，所以我们必须要先加锁，然后手动判断临界资源的就绪状态，通过状态进一步判断是等待，还是直接对临界资源进行操作。 但如果我们能事前得知，那就不需要加锁了，因为我们提前已经知道了临界资源的就绪状态了，不再需要手动判断临界资源的状态。所以如果我们有一把计数器，这个计数器来表示临界资源中小块儿资源的数目，比如队列中的每个空间就是小块儿资源，当线程想要对临界资源做访问的时候，先去申请这个计数器，如果这个计数器确实大于0，那不就说明当前队列是有空余的位置吗？那就可以直接向队列中push数据。如果这个计数器等于0，那就说明当前队列没有空余位置了，你不能向队列中push数据了，而应该阻塞等待着，等待计数器重新大于0的时候，你才能继续向队列中push数据。
线程池是一种管理线程的机制，它可以在需要时自动创建和销毁线程，以及分配和回收线程资源。线程池的主要优点是减少了频繁创建和销毁线程所带来的开销，提高了系统的稳定性和可扩展性。此外，线程池还可以有效地控制线程的数量，避免过多线程导致的资源竞争和系统过载
dispatch_group_create() + dispatch_group_wait()
生产者消费者模型（CP模型）是一种非常经典的设计，常常出现在各种 「操作系统」 书籍中，深受教师们的喜爱；这种模型在实际开发中还被广泛使用，因为它在多线程场景中是十分高效的！
在我们的工作中，多线程编程是一件太稀松平常的事。在多线程环境下操作一个变量或者一块缓存，如果不对其操作加以限制，轻则变量值或者缓存内容不符合预期，重则会产生异常，导致进程崩溃。为了解决这个问题，操作系统提供了锁、信号量以及条件变量等几种线程同步机制供我们使用。如果每次操作都使用上述机制，在某些条件下(系统调用在很多情况下不会陷入内核)，系统调用会陷入内核从而导致上下文切换，这样就会对我们的程序性能造成影响。
本文例子均在 Linux（g++）下验证通过，CPU 为 X86-64 处理器架构。所有罗列的 Linux 内核代码也均在（或只在）X86-64 下有效。
多读单写，简单说，就是对资源的访问分为两种状态，一种是读操作，另一种是写操作。由应用程序提示锁应该做哪种操作。当为读模式时，所有的写动作被悬挂，而读请求被允许通过，而写动作时，所有操作被悬挂。并且，读写切换时，有足够的状态等待，直到真正安全时，才会切换动作。
7月12日一款叫做TDengine的时序数据库项目在GitHub上开源了，这个项目一经发布就稳稳占据了GitHub排行榜的C位，目前TdEngine已经累积了5000多个star,并且连续一周排在上升榜首位。而且你要知道TdEngine的开发语言并不是火热的Python或JAVA，而是C语言。C语言无巧可取，虽见功夫，但是代码比较难读，能引发如此的关注绝对堪称奇迹，在我印象中即使是Mysql也没有达到如此的热度。
---- Hello、Hello大家好，我是木荣，今天我们继续来聊一聊Linux中多线程编程中的重要知识点，详细谈谈多线程中同步和互斥机制。 同步和互斥 互斥：多线程中互斥是指多个线程访问同一资源时同时只允许一个线程对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的； 同步：多线程同步是指在互斥的基础上（大多数情况），通过其它机制实现访问者对资源的有序访问。在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源
作者 | 马超 责编 | 张红月 出品 | CSDN博客 Serverless的核心理念就是函数式计算，开发者无须再关注具体的模块，云上部署的粒度变成了程序函数，自动伸缩、扩容等工作完全由云服务负责。 Serverless Computing，即”无服务器计算”，其实这一概念在刚刚提出的时候并没有获得太多的关注，直到2014年AWS Lambda这一里程碑式的产品出现。Serverless算是正式走进了云计算的舞台。2018年5月，Google在KubeCon+CloudNative 201
很多时候，我们做项目并不会创建那么多进程，而是创建一个进程，在该进程中创建多个线程进行工作。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
多线程的东西。我确实非常爱他们。可是每每想动手写点关于他们的东西。却总是求全心理作祟。始终动不了手。
文章主要介绍了在Linux系统中，如何利用自旋锁来实现线程之间的同步和互斥。主要包括了自旋锁的定义、工作原理、使用方式和注意事项，并通过实例介绍了如何在C语言中实现自旋锁。
同步问题是保证数据安全的情况下，让线程访问资源具有一定的顺序性，从而有效避免饥饿问题，叫做同步。
入门 包含了正确的头文件只能编译通过，没链接正确的库链接会报错。 一些常用的库gcc会自动链接。 库的缺省路径/lib /usr/lib /usr/local/lib 不知道某个函数在那个库可以nm -o /lib *.so | grep 函数名 man sin 会列出包含的头文件和链接的库名。 man 2 sin 2表示系统调用，3表示c库函数 一旦子进程被创建，父子进程一起从fork处被创建。 创建子进程为了争夺资源。 重定向用dup2函数 kill -l查看信号种类 pthread_mutex不跨进
当多线程并发执行并都需要访问临界资源时，因为每个线程都是不同的执行流，这就有可能导致数据不一致问题，为了避免此问题的发生，就需要对这块临界资源增加一些限制，一次只能有一个线程访问临界资源，即线程互斥。
非常想写点关于多进程和多线程的东西，我确实非常爱他们。可是每每想动手写点关于他们的东西，却总是求全心理作祟，始终动不了手。
上周参加了字节跳动的面试，整场下来一共70分钟，面试官非常Nice，无奈自己太过紧张，很多准备好的知识点都没有能够准确传达意思。
信号量强调的是线程（或进程）间的同步：“信号量用在多线程多任务同步的，一个线程完成了某一个动作就通过信号量告诉别的线程，别的线程再进行某些动作（大家都在sem_wait的时候，就阻塞在那里）。当信号量为单值信号量时，也可以完成一个资源的互斥访问。信号量测重于访问者对资源的有序访问，在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源。
给属性添加atomic 可以保证属性的setter和getter原子性操作，也就是保证setter和getter内部是线程同步的
条件变量是线程间同步的一种机制，本文分析条件变量的实现和使用。我们先看一下条件变量的定义。
现代操作系统基本都是多任务操作系统，即同时有大量可调度实体在运行。在多任务操作系统中，同时运行的多个任务可能：
1 互斥锁 在线程实际运行过程中，我们经常需要多个线程保持同步。 这时可以用互斥锁来完成任务。互斥锁的使用过程中，主要有 pthread_mutex_init pthread_mutex_destory pthread_mutex_lock pthread_mutex_unlock 这几个函数以完成锁的初始化，锁的销毁，上锁和释放锁操作。 1.1 锁的创建 锁可以被动态或静态创建，可以用宏PTHREAD_MUTEX_INITIALIZER来静态的初始化锁，采用这种方式比较容易理解，互斥锁是pthread_m
一般情况的理念中，只要我们对资源进行整体加锁，就默认了我们对这个资源整体使用。但是在实际的情况下，可能存在一份公共资源允许多个线程同时访问不同的区域！
引入： 举个例子，我们想买个生活用品，但是没有交易场所的话，我们就只能直接去供货商那里去买。我们每人每次买一两件，对于供货商来说，为了这一两件商品去开启厂子里的机器进行生产，是很亏本的事情。因此，有了交易场所——超市等存在，它们作为交易商品的媒介，工作就是集中需求，分发产品。 消费者和生产者之间通过超市进行交易。当消费者没有消费的同时，生产者也可以继续生产；当消费者过来消费的同时，生产者也可以停止生产（例子：周内生产者上班生产商品，学生上学不来超市购买商品；周末生产者放假休息，不进行生产工作，学生过来超市购买商品）。由此，生产和消费这两件事就可以解耦了，我们把临时保存产品的场所称为缓冲区。
活锁、死锁本质上是一样的，原因是在获取临界区资源时，并发多个进程/线程声明资源占用(加锁)的顺序不一致，死锁是加不上就死等，活锁是加不上就放开已获得的资源重试，其实单机场景活锁不太常见。举个例子资源A和B，进程P1和P2，
1. 读写锁有三种状态，读模式下加锁（共享）、写模式下加锁（独占）以及不加锁。
学生是典型的消费者，供货商是典型的生产者。假设学生有泡面、火腿肠、玩具等等的需求，而供货商会生产尽可能覆盖学生需求的商品，但是一般并不会直接卖给学生，而是供货给超市，从而在超市里做买卖。
2. 读写锁是“读模式加锁”时， 如果线程以读模式对其加锁会成功；如果线程以写模式加锁会阻塞。
续接上一篇“线程同步”：https://blog.csdn.net/zy010101/article/details/105967289
开发成长之路（1）-- C语言从入门到开发（入门篇一） 开发成长之路（2）-- C语言从入门到开发（函数与定制输入输出控制函数） 开发成长之路（3）-- C语言从入门到开发（讲明白指针和引用，链表很难吗？） 开发成长之路（4）-- C语言从入门到开发（距离开发，还差这一篇） 开发成长之路（5）-- C语言从入门到开发（仿ATM机项目，我写的第一个项目） 开发成长之路（6）-- C++从入门到开发（C++入门不难） 开发成长之路（6）-- C++从入门到开发（C++知名库：STL入门·容器（一）） 开发成长之路（7）-- C++从入门到开发（C++知名库：STL入门·容器（二）） 开发成长之路（8）-- C++从入门到开发（C++知名库：STL入门·容器（三）） 开发成长之路（9）-- C++从入门到开发（C++知名库：STL入门·空间配置器） 开发成长之路（10）-- C++从入门到开发（C++知名库：STL入门·算法） 开发成长之路（11）-- STL常用函数大集合 开发成长之路（12）-- Linux网络服务端编程（通识篇之熟悉操作环境） 开发成长之路（13）-- Linux网络服务端编程（通识篇）
读写锁其实还是一种锁，是给一段临界区代码加锁，但是此加锁是在进行写操作的时候才会互斥，而在进行读的时候是可以共享的进行访问临界区的。 读写锁和互斥量（互斥锁）很类似，是另一种线程同步机制，但不属于POSIX标准，可以用来同步同一进程中的各个线程。当然如果一个读写锁存放在多个进程共享的某个内存区中，那么还可以用来进行进程间的同步，
我们使用线程操作临界资源的时候要先去判断临界资源是否满足条件：并不能事前得知，只能通过先加锁判断，再检测，再操作、解锁，因为我们在操作临界资源的时候，有可能不就绪，但是我们无法提前得知，所以只能先加锁再检测，根据检测结果，决定下一步怎么走，那我们能不能通过一种办法提前得知是否满足条件呢？这样就不用加锁了，直接让线程等待或者访问：答案就是信号量
消费者定期去超市买东西，买完在拿回来，即消费行为 供货商作为生产者，由供货商把商品生产到超市
引入：举个例子，比如我们学生想买东西，但是如果没有交易场所超市，那么我们只能去供货商去买东西，那我们只能如果要一件供货商只能生成一件，对于供货商来说生成的成本太大了，所以有了交易场所超市这个媒介的存在。目的就是为了集中需求，分发产品。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/169974.html原文链接：https://javaforall.cn
Redis单线程是指处理的事件循环的线程是单一的，命令执行主要是依靠单一线程执行的。Redis使用单线程是因为基于内存速度快，而且多路复用也能确保redis能同时处理多个请求，在Redis 6.0引入多线程是因为在某些操作要优化，比如删除操作。
但是并不是非常完美，因为多线程常常伴有资源抢夺的问题，作为一个高级开发人员并发编程那是必须要的，同时解决线程安全也成了我们必须要要掌握的基础
Pthreads 有几种工作模型，例如 Boss/Workder Model、Pileline Model(Assembly Line)、Background Task Model、Interface/Implementation Model，详细介绍可以参考 pthread Tutorial，这里给出一个流水线模型(Pipeline Model)的简单示例。在该示例中，主线程开启了两个子线程，一个子线程用来读取文件，一个子线程用于将结果写入文件，而主线程自身用来计算。
Redis 是一个高性能服务端的典范。它通过多路复用 epoll 来管理海量的用户连接，只使用一个线程来通过事件循环来处理所有用户请求，就可以达到每秒数万 QPS 的处理能力。下图是单线程版本 Redis 工作的核心原理图（详情参见：单线程 Redis 如何做到每秒数万 QPS 的超高处理能力！）。
先看看互斥锁，它只有两个状态，要么是加锁状态，要么是不加锁状态。假如现在一个线程a只是想读一个共享变量 i，因为不确定是否会有线程去写它，所以我们还是要对它进行加锁。但是这时又有一个线程b试图去读共享变量 i，发现被锁定了，那么b不得不等到a释放了锁后才能获得锁并读取 i 的值，但是两个读取操作即使是同时发生的，也并不会像写操作那样造成竞争，因为它们不修改变量的值。所以我们期望在多个线程试图读取共享变量的时候，它们可以立刻获取因为读而加的锁，而不是需要等待前一个线程释放。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
