【Linux】线程同步与互斥

【Linux】线程同步与互斥

一. 线程互斥

引入

要理解线程互斥的概念,首先我们要先从,为什么线程需要互斥这个点切入。

我们先来看看下面这串代码,这是一段有关抢票的代码

运行结果:



我们让三个线程同时进行抢票,发现票数被抢到了负数,这样的结果当然不符合我们的预期。

票数抢到负数是因为线程产生了竞态关系,当一个线程达到 0 时,另一个线程可能刚好执行了 - - 的代码,此时当前的线程在进行 - - 就出现了负数。

当多个线程访问共享资源时,如果不考虑线程安全问题,可能会导致数据丢失,错误等原因。

1. 进程互斥基本概念与背景

(1)互斥与并发

互斥就是相互排斥,有你没我,与互斥相对的一组是并发,并发就是可以同时存在。

我们将这组概念带入线程中,互斥就是在同一时间,只能有一个线程对共享资源进行访问;线程并发就是在同一时间,线程同时竞争共享资源。

(2)同步与异步

同步与异步是相对的,同步必须等待被调用方执行完毕并返回结果才能继续执行后续操作,相当于线程被阻塞住了。异步就是多个线程自己执行自己的内容,不需要关心其他的线程。

(3)操作原子性

原子性操作是指当一个线程执行一段代码的时候,此时不能切换到其他线程,必须执行完当前线程的代码才能进行切换。

(4)临界区和临界资源

临界资源是指在多线程环境下,不能被线程同时访问和使用的资源,即被使用的共享资源就是临界资源。临界区指访问临界资源的代码块,从起点到终点,这块地方就是临界资源


为了保护这些临界资源,操作系统提供了一些机制。给临界资源进行上锁,使用信号量进行访问控制等等。

2. 互斥量 mutex

(1)案例解析

对于上述的抢票代码,票数产生了负数。在线程代码中 usleep 进行了一段休眠,这会导致很多线程进入该代码段,而且ticket- - 本身就不是一个原子操作,所以说,要解决上述的问题,我们就要对临界区进行保护,于是我们便有了锁,用来对临界资源进行上锁,使得在临界区当中,每次运行只允许一个线程执行。

(2)系统接口

操作系统给出了互斥锁(mutex)用于解决当前情况。它可以保证在相同时间下,只有一个线程可以访问共享资源或代码段。互斥锁的用法也很简单,首先定义一个互斥锁对象,在临界区处进行上锁,在临界区末尾释放锁。线程拿到锁进行原子操作,执行完临界区代码后会释放锁,其他的线程会在临界区外部等待锁,只有拿到了锁才能进入临界区进行访问。这样使得临界区每次进行访问只有拥有锁的线程才能进行访问,保证了线程执行的安全性。


下面我们来介绍一下 POSIX 线程库封装的一些线程互斥接口

POSIX 线程库中用于操作互斥量的函数都以 pthread_mutex 打头:

初始化互斥量:

静态初始化互斥量:pthread_mutex_t

静态初始化的互斥量不需要进行 destroy操作,程序结束会自动回收
动态初始化互斥量:pthread_mutex_init

参数:

mutex:指向类型变量的指针

mutexattr:给 mutex 设置属性,我们一般使用nullptr 默认值

销毁互斥量:

动态分配后的互斥锁若不使用需要进行回收

pthread_mutex_destroy:

参数:

mutex:指向类型变量的指针

互斥量加锁和解锁:

对临界区资源进行加锁解锁,当互斥量处于未锁状态,该函数会将互斥量锁定,若其他线程已经锁定该互斥量,那么该执行流会被阻塞挂起,等待互斥量解锁

pthread_mutex_lock:

pthread_mutex_unlock:

参数:

mutex:指向类型变量的指针

全局锁与局部锁

全局锁:

全局锁是全局变量或静态变量,所有线程都可以访问,优点是可以保护全局资源,缺点在于所有的线程都可以访问,频繁的访问导致并发效率降低

局部锁:

局部锁是定义在局部变量的锁,它服务于局部某个特定的函数当中,虽然作用范围有限,但服务于专一对象并发效率高。

(3)实现原理

上锁解锁都是原子性的操作,原子性的操作要求CPU在执行指令的时候要尽可能的短,只执行一条语句。我们来看一下伪代码

锁的操作是原子的,当一把锁被频繁的调用时,意味着它对 CPU 性能的开销也逐渐增大。

互斥锁的创建销毁,加锁解锁,等待唤醒,竞争阻塞都会对资源进行消耗。所以说,我们要合理规划使用锁资源,尽量减少互斥锁的保护范围,缩短锁的持有时间尽快释放锁,根据不同场景用不同的锁来进一步提升效率。

(4)互斥锁与自旋锁

互斥锁和自旋锁是两种常见的同步机制,它们的区别在于,当一个线程获取一个被占用的锁时,互斥锁会进行挂起等待,等待锁的释放;而自旋锁会不断地循环访问,直到锁的释放。互斥锁可以避免浪费CPU资源,不需要频繁进行访问,但是会增加上下文切换开销;自旋锁频繁访问会增加CPU资源消耗,但可以减少上下文的切换。

(5)互斥量封装

#pragma once #include <iostream> #include <pthread.h> using namespace std; class Mutex { public: Mutex() { int n = pthread_mutex_init(&mutex, nullptr); (void)n; } void Lock() { pthread_mutex_lock(&mutex); } void Unlock() { pthread_mutex_unlock(&mutex); } ~Mutex() { int n = pthread_mutex_destroy(&mutex); } private: pthread_mutex_t mutex; }; class LockGuard { public: LockGuard(Mutex &mutex) : _mutex(mutex) { _mutex.Lock(); } ~LockGuard() { _mutex.Unlock(); } private: Mutex &_mutex; };

二. 线程同步

1. 同步的概念与竞态条件

什么是同步?同步就是在安全的前提下你,线程按照某种顺序访问临界资源。什么是竞态条件?在多线程中,同时访问或修改共享资源,最终结果依赖于线程执行的相对顺序,从而导致程序出现不可预测行为的现象。

2. 条件变量

(1)条件变量概念

条件变量就是一个条件,当线程不满足该条件时,就主动进行阻塞,不需要轮询的访问;当条件满足时,根据队列排序对线程进行唤醒。这样节省了 CPU 的资源消耗,它通常与互斥锁绑定。

(2)系统接口

下面我们来介绍一下 POSIX 线程库封装的一些线条件变量接口

POSIX 线程库中用于操作条件变量的函数都以 pthread_cond 打头:

初始化:

静态初始化条件变量:pthread_cond_t

静态初始化的条件变量不需要 destroy 进行销毁,但是只能指向一个对象
动态初始化条件变量:pthread_cond_init

动态创建的条件变量较为灵活,可以更改指向的锁对象,当我们不使用该条件变量时,我们需要 进行 destroy 销毁

销毁:

动态创建的条件变量在结尾需要进行销毁

pthread_cond_destroy:

参数:

cond:当前条件变量指针

返回值:

成功返回0,失败返回错误码

等待条件:

当条件不满足时,线程会自动释放锁进入阻塞状态,其他的线程可以拿被释放的锁执行任务,被阻塞的线程需要等待唤醒信号,被唤醒的线程将会重新获取锁

pthread_cond_wait:

参数:

cond:当前条件变量指针

mutex:互斥量,即互斥锁

返回值:

成功返回0,失败返回错误码

唤醒等待:

通常与等待线程的接口一同使用,用于唤醒线程(等待前必须有锁)

pthread_cond_broadcast:

唤醒所有等待条件变量的线程

参数:

cond:当前条件变量指针

返回值:

成功返回0,失败返回错误码
pthread_cond_signal:

唤醒单个等待条件变量的线程

参数:

cond:当前条件变量指针

返回值:

成功返回1,失败返回错误码

(3)注意事项

线程唤醒和线程等待必须配合锁进行使用,类似于我们使用一个公共微波炉,只有持有锁的人才能使用这个微波炉。如果我们在持有锁前进行等待,就相当于微波炉是空的,但你确一直在等待。当我们进入临界区后,相当于一排人排队等着微波炉(wait等待),唤醒相当于前一个人使用完微波炉轮询到下一个。


下面我们来讲一下虚假唤醒,所谓的虚假唤醒是因为错误的认为“条件已满足”,从而执行不符合的操作,最典型的就是 if 语句

我们来看一下下面这串代码

当线程队列为空时,if 语句为 true ,进入了 if 循环体当中进入线程等待,若线程等待成功后,此时不会再次进行 if 判断,此时直接执行 pop 操作,就会导致出错。

处理虚假唤醒的唯一方法就是使用 while 循环而不是 if 条件语句的判断,我们来看一下正确的代码

此时,线程等待成功后会再次进入 while 循环进行判断,队列不为空才继续向下执行。

线程的唤醒信号是不被缓存的,当一个线程发送了一个唤醒信号时,如果没有任何线程在等待该条件变量,这个信号就会直接“失效”不会进行缓存。例如,当我们将唤醒信号放在等待操作前,当信号丢失时,等待线程会永久阻塞。

我们来看一下正确的使用方法

我们可以使用一个计数器用来记录信号传递次数,用计数器的方式代替信号唤醒机制,这样即使信号失效了,也可以让线程知道是否需要进行等待。

避免信号丢失的关键在于用共享变量记录条件状态在等待前先检查变量

3. 生产者消费者模型

(1)模型概念

生产者消费者模型要符合 “321” 原则,即 3 种关系,2 个 角色,1 个交易场所。下面我们按照321来讲解生产者消费者模型。

类似于我们日常生活,在我们生活中,工厂一般扮演着生产者的角色生产各种各样的东西,许多工厂的货物被集中到超市进行售卖,由消费者来在超市中购买货物。工厂不会直接的把货物交到消费者的手中,消费者也不会直接的去工厂进行购入货物。将这套模型运用到计算机中,此时,工厂就是生产者,负责生产数据,任务,消息等等;超市就是共享缓冲区,来获取数据提供数据;消费者在超市中取数据将数据进行进一步处理。这套模型完成了数据生成与数据处理的解耦,提升了程序的稳定性。

1个交易场所就是共享内存,2个角色分别是生产者消费者,3种关系为生产者与生产者的关系消费者与消费者的关系,生产者与消费者的关系。

下面我们就来讲讲者这三种关系

生产者与生产者的关系是竞争关系,不同的生产者需要竞争锁,因为向共享区中写入数据需要保证原子性,它们之间需要竞争缓冲区的写入权。

消费者和消费者的关系是竞争关系,不同的消费者也需要竞争锁,保证消费者取数据不取重,消费者之间需要竞争读取数据权。

生产者与消费者之间是协助关系,生产者向共享区当中写入数据,此时应该通知消费者共享区当中有数据;消费者进入共享区当中消费数据,当数据消耗完后,需要通知生产者及时生产数据。

(2)模型优点

生产者消费者模型完成了数据生产和数据使用之间的解耦操作,生产者无需知道消费者的存在消费者也无需生产者的存在。后续可以加入新的生产者或者消费者扩展性强。同时,该模型还可以处理速度不匹配的问题,例如生产速度块,可以在缓冲区当中进行缓存。

(3)queue模拟阻塞队列的生产消费模型

#include <iostream> #include <queue> #include <pthread.h> #include "Mutex.hpp" #include "Cond.hpp" using namespace std; static int defaultnum = 10; template <typename T> class Blockqueue { private: bool _isfull() { return _q.size() >= defaultnum; } bool _isempty() { return _q.empty(); } public: Blockqueue(int cap = defaultnum) : _s_sleep(0), _p_sleep(0), _cap(cap) { } void Enqueue(const T &in) { { LockGuard(_mutex); while (_isfull()) { _p_sleep++; cout << "生产队列已满" << endl; _full_cond.Wait(_mutex); _p_sleep--; } q.push(T); if (_s_sleep > 0) { _empty_cond.Signal(); cout << "唤醒消费者" << endl; } } } T Pop() { T data; { LockGuard(_mutex); while (_isempty()) { _s_sleep++; cout << "消费队列为空" << endl; _empty_cond.Wait(_mutex); _s_sleep--; } data = q.front(); q.pop(); if (_p_sleep > 0) { _full_cond.Signal(); cout << "唤醒生产者" << endl; } } return data; } ~Blockqueue() { } private: queue<T> _q; // 存放 int _cap; // 容量 int _s_sleep; // 消费者休眠数 int _p_sleep; // 生产者休眠数 Mutex _mutex; Cond _full_cond; // 队列满条件 Cond _empty_cond; // 队列空条件 };

4. 条件变量使用规范以及封装

等待条件代码:

给条件发送信号代码:

条件变量接口封装:

#pragma once #include <iostream> #include <pthread.h> #include "Mutex.hpp" using namespace std; class Cond { public: Cond() { int n = pthread_cond_init(&cond,nullptr); } void Wait(Mutex &mutex) { pthread_cond_wait(&cond,mutex.Get()); } void Signal() { pthread_cond_signal(&cond); } void Broadcast() { pthread_cond_broadcast(&cond); } ~Cond() { int n = pthread_cond_destroy(&cond); } private: pthread_cond_t cond; };

5. 环形队列生产模型

(1)POSIX 信号量

POSIX 信号量与 SystemV 信号量作用相同,都是原子操作的计数器,但 POSIX 的信号量主要服务于线程和进程中。

下面我们来介绍一下相关接口:

sem_init:

信号量初始化

参数:

sem:指向信号量的指针

pshared:0表示线程间共享,非0表示进程间共享

value:信号量初始值

返回值:

成功返回0,失败返回-1

sem_destroy:

信号量销毁

参数:

sem:指向信号量的指针

返回值:

成功返回0,失败返回-1

sem_wait:

信号量等待,信号量数量-1

参数:

sem:指向信号量的指针

返回值:

成功返回0,失败返回-1

sem_post:

归还信号量,信号量数量+1

参数:

sem:指向信号量的指针

返回值:

成功返回0,失败返回-1

(2)环形队列封装

Ringqueue.hpp:

Main.cc:

三. 死锁

死锁指在进程中各个进程占有不会释放的资源,但因互相申请被其他进程所占用的资源导致处于一种永久的等待状态。

假设现在有两个线程,访问临界资源需要两把锁,此时线程A占了一把锁,线程B占了一把锁,它们互相都想要对方的锁,导致进入两边都在等待对方手里的锁因此进入了线程等待。

此时,线程A持有锁1,线程B持有锁2,线程A尝试获取锁2,线程B尝试获取锁1.它们都互相申请对方的锁但是不释放自己的锁。

那么该如何避免死锁呢?拿上述的例子来讲

方法一:

设置一个时间限制,若超出了当前的时间还未获取到锁那么就主动释放锁。

方法二:

我们可以让所有线程必须按照固定顺序获取资源,必须先获取锁1之后才能获取锁2。我们按照顺序给临界资源上锁即可

错误示范:

正确示范:

方法三:

一次性的获取所有的资源,我们可以让线程一次性获取两把锁,这样就不会造成一人一把锁的状况

正确示范:

总结:

线程同步与互斥是多线程编程的 “基石”,核心目标是解决 “数据安全” 和 “顺序可控” 问题:

互斥:用锁(互斥锁、读写锁)保证共享资源的原子访问,避免数据竞争;

同步:用条件变量、信号量协调线程执行顺序,满足逻辑依赖;

避坑重点:锁必须成对使用,条件变量需处理虚假唤醒,同步逻辑需避免死锁。

Read more

Claude Code Superpowers -“让 AI 像资深工程师一样工作,而不是像只会写代码的实习生。”‌

Claude Code Superpowers -“让 AI 像资深工程师一样工作,而不是像只会写代码的实习生。”‌

1、什么是Superpowers Superpowers不是独立工具,是Claude Code的插件系统。 装上之后,Claude Code会自动多出一套”技能树”: brainstorming:帮你理清需求再动手,不是瞎写 test-driven-development:强制TDD流程,先写测试 systematic-debugging:4步调试法,找根因 writing-plans:把需求拆成2-5分钟的小任务 subagent-driven-development:子代理流水线干活 核心就一句话:让AI不要瞎搞,按照专业开发流程来。 2、核心价值 “让 AI 像资深工程师一样工作,而不是像只会写代码的实习生。”‌ 它认为,AI 编程的主要问题不是“不会写”,而是“没有流程”。它通过一套可组合的“技能”(Skills),将传统开发中容易被跳过的关键环节变成不可绕过的自动化节点,从而解决 AI 编程中常见的“方向跑偏”、“忽略测试”、“代码质量不稳定”等问题。 其核心价值体现在: * ‌强制测试驱动开发

AI赋能原则5解读思考:AI时代必须面对的现实与应对策略-当“最聪明的大脑”犯低级错误

AI赋能原则5解读思考:AI时代必须面对的现实与应对策略-当“最聪明的大脑”犯低级错误

目录 一、AI 的问题不是“偶尔犯错”,而是“结构性错误” (一)概率性:输出永远是“最可能”,不是“最正确” (二)上下文依赖:轻微变化引发“答案蝶变” (三)难以重现:AI 的“不稳定性”不是缺陷,而是本质 (四)幻觉不可消除:语言模型天然会“编故事”而不是“求真” 二、AI“错误的现实”:从隐性隐患到显性风险 (一)企业级错误:从“产品瑕疵”到“系统风险” (二)个人用户的风险:隐蔽且高危 (三)错误的叠加效应:AI“谣言裂变”机制 三、我们必须面对的现实:

免费获得大模型的Api-Key的方法:英伟达提供GLM-4.7、Minimax M2.1模型和GitHub的AI大模型API申请

免费获得大模型的Api-Key的方法:英伟达提供GLM-4.7、Minimax M2.1模型和GitHub的AI大模型API申请 最近一直在玩OpenClaw,无奈OpenClaw是个消耗token的高手!随随便便问了几个问题就能吃掉百万的token数,妥妥的吞金兽,如果有免费的token就好了! 今天就给大家介绍英伟达和Github的免费大模型API Key的获取方法。 传送门: * • OpenRouter提供的DeepSeek-R1-70B的大模型免费用 * • 获取各大人工智能AI工具通过API和KEY调用的方法 英伟达-Nvidia的免费API Key 说到英伟达,大家的第一反应可能是"卖显卡的大佬"。但很少有人意识到,拥有强大算力的英伟达,也在积极布局AI云服务市场。这波免费开放API的策略,本质上是一个聪明的生态布局——通过免费服务吸引开发者,为未来的商业变现铺路。   注册账号 1.打开英伟达官网 https://build.nvidia.com 点击“Login”   2.输入邮箱 输入邮箱、密码   3.验

破除各种限制,手把手教你本地部署大语言模型,打造私人AI

破除各种限制,手把手教你本地部署大语言模型,打造私人AI

随着 AI 应用的快速普及,它已经悄然融入了人们的日常生活。相信大家对 ChatGPT、豆包、元宝这些 AI 应用已经不再陌生,并且几乎离不开它们了。但是,随着这些商用 AI 的广泛应用,一些问题也随之而来。由于监管日益严格,商用大模型的“输出限制”越来越多,动不动就触发拦截;另一方面,很多人也担心自己的敏感信息(比如商业机密、个人敏感信息,或者一些不便于给别人知道的对话)被大厂收集导致隐私泄露。这就导致很多时候,虽然 AI 很智能,但在某些特定场景下却显得非常“鸡肋”。那么,在自己的电脑上本地部署一个完全受自己控制的大语言模型的需求对个人用户就变得非常迫切。本文就将一步一步教你在本地电脑上部署一个专属于你自己的AI。 第一步:认识并安装 Ollama 简单来说,Ollama 是一个开源的本地大模型运行框架。在过去,想要在自己的电脑上运行一个几十亿参数的大语言模型(LLM),你需要懂 Python、配置复杂的代码环境、处理各种让人头疼的报错。而