Go源码--sync库（2）

简介

这边文章主要讲解 Sync.Cond和Sync.Rwmutex

Sync.Cond

简介 sync.Cond 经常用来处理 多个协程等待 一个协程通知 这种场景， 主要 是阻塞在某一协程中 等待被另一个协程唤醒 继续执行 这个协程后续的功能。cond经常被用来协调协程对某一资源的访问 ants协程池就用了这种机制
本文主要讲解Cond 的源码 ，关于其使用已经有许多例子了 本文直接略过
cond 的结构体如下

type Cond struct {
	noCopy noCopy // 告诉编译器 本结构体不能复制

	// L is held while observing or changing the condition
	L Locker            

	notify  notifyList  // 在 Wait 上阻塞的线程 这边只记录 阻塞携程的 指针 真正阻塞是调用的GMP模型 相关功能
	checker copyChecker // 复制检查
}


//使用时 需要 新建一个Cond变量 入参必须有一个锁 用来 锁定 Cond 的 Wait()调用所涉及的资源
func NewCond(l Locker) *Cond {
	return &Cond{L: l}
}

其 主要有三个函数 如下

Wait()

用来阻塞 协程
其源码如下

func (c *Cond) Wait() {
	c.checker.check()                     // 复制检查
	t := runtime_notifyListAdd(&c.notify) // 等待数量+1； 其使用了 汇编的 LOCK 命令来实现加1的原子性操作
	c.L.Unlock()                          // 解锁 ；Wait()代码调用之前必须有 Lock ，可以看到 锁c.L 的作用域直接到了这里
	                                      // 因为 Wait() 一般用在 协程中 且共享内存（也就是变量等）

	runtime_notifyListWait(&c.notify, t)  // 所有协程都阻塞在这里；  大概功能是 首先将本协程指针放入notifyList等待队列
	                                      // 然后进行GMP模型调度 释放当前M 将当前 G指针加入等待队列等待被唤醒 M开始等待可用的G
										  // 所以 g指针存在于两个地方 一个 notifyList 列表 一个 等待队列 这样方便唤醒
	c.L.Lock()                            // 解锁
}

实现wait 效果的 是 runtime_notifyListWait(…)函数 我们来研究下 其代码位置是 runtime/runtime2.go/notifyListWait
源码如下

func notifyListWait(l *notifyList, t uint32) {

	// 上锁 细节可以自行研究
	lockWithRank(&l.lock, lockRankNotifyList)

	// Return right away if this ticket has already been notified.
	if less(t, l.notify) {
		unlock(&l.lock)
		return
	}

	// Enqueue itself.
	// sudog 是某个协程的 阻塞状态信息
	s := acquireSudog()
	// 获取当前协程的指针
	s.g = getg()
	// 可以看做 当前协程在 等待列表中的索引
	s.ticket = t
	s.releasetime = 0
	t0 := int64(0)
	if blockprofilerate > 0 {
		t0 = cputicks()
		s.releasetime = -1
	}
	// 将协程信息 插入 尾部
	if l.tail == nil {
		l.head = s
	} else {
		l.tail.next = s
	}
	l.tail = s
	// 这里涉及到 GMP模型调度 大概功能是 释放当前M 将当前 G加入等待队列等待被唤醒 M开始等待可用的G
	goparkunlock(&l.lock, waitReasonSyncCondWait, traceBlockCondWait, 3)
	if t0 != 0 {
		blockevent(s.releasetime-t0, 2)
	}

	// 释放当前 sudog结构体
	releaseSudog(s)
}
Signal()

唤醒 某一个 调用 Wait()阻塞的协程 继续执行其后续代码
其源码如下

func (c *Cond) Signal() {
	c.checker.check()
	runtime_notifyListNotifyOne(&c.notify)  // link runtime/sema.go/notifyListNotifyOne
											// notifyListNotifyOne 主要使用了GMP调度器的唤醒功能（runtime/proc.go/goready(...)）：从notifyList获取某个需要唤醒的g协程指针，
											// 使用GMP调度算法 唤醒这个g协程
											// 将它（g）放入（使用M 操作）运行队列中 必要时唤醒处理器（p）处理这个协程
}

其中runtime_notifyListNotifyOne的唤醒功能使用的是 GMP调度算法 的 ready 调用链 如下
在这里插入图片描述

ready源码如下

func ready(gp *g, traceskip int, next bool) {
	if traceEnabled() {
		traceGoUnpark(gp, traceskip)
	}

	// 获取 当前协程状态
	status := readgstatus(gp)

	// Mark runnable.
	// 获取当前协程 所属的 M
	mp := acquirem() // disable preemption because it can be holding p in a local var
	if status&^_Gscan != _Gwaiting {
		dumpgstatus(gp)
		throw("bad g->status in ready")
	}

	// status is Gwaiting or Gscanwaiting, make Grunnable and put on runq
	// 将当前协程状态 由等待中 变为可运行
	casgstatus(gp, _Gwaiting, _Grunnable)

	// 通过 M 将协程 G 放入可运行队列
	runqput(mp.p.ptr(), gp, next)
	// 唤醒一个 P
	wakep()
	releasem(mp)
}

可以看到 这段代码 有了我们熟悉的G、M 和P

Broadcast()

唤醒所有 调用 Wait()阻塞的协程 继续执行其后续代码
其源码如下

func (c *Cond) Broadcast() {
	c.checker.check()
	runtime_notifyListNotifyAll(&c.notify) // 主要功能跟 runtime_notifyListNotifyOne 一样 但这个函数 调用的for循环 遍历 整个notifyList列表 唤醒所有协程
}

其底层也就相当 for 循环 执行 了 ready函数

Sync.Rwmutex

读写锁 是为了 解决 mutex的严格互斥的缺点，读读可以并发、读写有条件互斥、写写严格互斥
有争议的就是 读写有条件互斥 这是什么意思呢 我们首先 介绍下 读和写的两种优先模式

  1. 读写时 读优先
    只要有读操作来写操作就阻塞，一直到没有读操作为止，可能会造成写锁饥饿， 这种适合读操作远远大于写操作的场景
  2. 读写时 写优先
    写操作来时 后续的读操作全部阻塞 但是 写操作前的读操作需要完成
    rwmutex 就是采用写优先 所以 有条件互斥 是 写之前的读操作 可以继续完成 写之后的读操作就需要阻塞了

接下来我们来看源码
RWMutex 结构体如下：

type RWMutex struct {
	w           Mutex        // held if there are pending writers                     //  当有写操作挂起时 起作用 控制写操作的时 悲观锁
	writerSem   uint32       // semaphore for writers to wait for completing readers  // 写操作等待完成读操作的信号量
	readerSem   uint32       // semaphore for readers to wait for completing writers  // 读操作等待完成写操作的信号量
	readerCount atomic.Int32 // number of pending readers  // 当前挂起的读操作数，也就是写操作之前和之后发生的 在执行中的总的读操作。readerCount 并发安全 使用 Lock 锁总线
	readerWait  atomic.Int32 // number of departing readers  // 比写操作早到的读操作的数量 执行了 RLock() 但是没执行 RUnlock  
	                                                         // 执行链路  Rlock--->Lock()-->Runlock()
}

其重要的 函数有四个 RLock()、Runlock()、Lock()、Unlock()，其中前两个是控制读操作的，后两个控制写。

  • RLock()：根据一定条件来使得读协程阻塞
  • Runlock()：根据一定条件来唤醒写协程
  • Lock(): 根据一定条件来阻塞写协程
  • Unlock()：根据一定条件来唤醒其后到达的读协程 并释放写锁

我们分别来看下其代码：

RLock()
func (rw *RWMutex) RLock() {
	if race.Enabled {
		_ = rw.w.state
		race.Disable()
	}
	if rw.readerCount.Add(1) < 0 { // 小于0 证明前方有写操作(因为写操作会首先readerCount置为小于0) 则后来的读操作阻塞
		// A writer is pending, wait for it.
		runtime_SemacquireRWMutexR(&rw.readerSem, false, 0) // 写之后的读操作阻塞，采用GMP模型 中的功能 将当前G 睡眠 释放 M
	}
	if race.Enabled {
		race.Enable()
		race.Acquire(unsafe.Pointer(&rw.readerSem))
	}
}
Runlock()
func (rw *RWMutex) RUnlock() { // 执行这个函数 有两种情况
	if race.Enabled {
		_ = rw.w.state
		race.ReleaseMerge(unsafe.Pointer(&rw.writerSem))
		race.Disable()
	}
	if r := rw.readerCount.Add(-1); r < 0 { // 挂起的数量-1 如果挂起的协程数量是负数 说明 有写操作阻塞 则需要检查是否唤起写操作
		// 如果r>=0 ：  可能是 Rlock-->Runlock() --->Lock()-->Unlock() 这种情况 readerCount不为负值
		// Outlined slow-path to allow the fast-path to be inlined

		// r<0 开始递减 在写操作之前挂起的读操作数 也就是 readerWait 数 什么情况下会造成这种情况呢 在写操作之前执行 这种情况是 执行完毕 Rlock() 后 写操作 Lock() Runlock()
		// 也就是 Rlock--->Lock()-->Runlock() 这种顺序  这种情况会造成 readerCount为负值
		rw.rUnlockSlow(r)
	}
	if race.Enabled {
		race.Enable()
	}
}

其中 rw.rUnlockSlow( r)的作用是 readerWait数量-1 达到条件后 唤醒写操作 代码如下

func (rw *RWMutex) rUnlockSlow(r int32) {
	if r+1 == 0 || r+1 == -rwmutexMaxReaders {
		race.Enable()
		fatal("sync: RUnlock of unlocked RWMutex")
	}
	// A writer is pending.
	if rw.readerWait.Add(-1) == 0 { // 写之前的读协程数量-1
		// The last reader unblocks the writer. // 写之前的最后一个 读操作 解锁 写操作
		runtime_Semrelease(&rw.writerSem, false, 1)
	}
}
Lock()
func (rw *RWMutex) Lock() {
	if race.Enabled {
		_ = rw.w.state
		race.Disable()
	}
	// First, resolve competition with other writers.
	rw.w.Lock() // 将写操作跟其他写操作 进行互斥
	// Announce to readers there is a pending writer.
	r := rw.readerCount.Add(-rwmutexMaxReaders) + rwmutexMaxReaders // 将 readerCount 置为负数 用于阻塞后续 读操作；r是readerCount原始值
	// Wait for active readers.
	if r != 0 && rw.readerWait.Add(r) != 0 { // 将现有 写协程之前的读数量 加入到 等待数量中去 翻译成人话 比写操作早到的 读操作数量 如果不是0 也就是大于0 则写操作需要挂起
		runtime_SemacquireRWMutex(&rw.writerSem, false, 0) // 写协程挂起；GMP 模型 G进入等待队列休眠 M释放  注意：这里是获得写锁的协程睡眠
	}
	if race.Enabled {
		race.Enable()
		race.Acquire(unsafe.Pointer(&rw.readerSem))
		race.Acquire(unsafe.Pointer(&rw.writerSem))
	}
}

其中 const rwmutexMaxReaders = 1 << 30 为什么是这个数 不是 1<<31-1
解答：readerCount 高31位表示是否有写锁，高32表示是否有写锁在等待 则最大就是 1<<30-1 为了使得 其操作后为确定为负数 所以取值 1<<30

Unlock()
func (rw *RWMutex) Unlock() {
	if race.Enabled {
		_ = rw.w.state
		race.Release(unsafe.Pointer(&rw.readerSem))
		race.Disable()
	}

	// Announce to readers there is no active writer.
	r := rw.readerCount.Add(rwmutexMaxReaders) // 将readerCount 还原为原始值 说明没有 写操作了，这时 其值是 写操作后续的读操作
	if r >= rwmutexMaxReaders {
		race.Enable()
		fatal("sync: Unlock of unlocked RWMutex")
	}
	// Unblock blocked readers, if any.
	for i := 0; i < int(r); i++ { // 将读操作挨个唤醒
		runtime_Semrelease(&rw.readerSem, false, 0)
	}
	// Allow other writers to proceed.
	rw.w.Unlock() // 允许其他的写操作继续拥有锁
	if race.Enabled {
		race.Enable()
	}
}

无论是mutex还是rwmutex 其代码量都不大 但是逻辑都比较复杂 需要反复研读大神的代码

下面我们来看下 各种情况的 readCount 和 readWait 的数量 如下图
在这里插入图片描述

大家思考下 引入 rwmutex时能不能仅仅使用RLock()和Runlock()或者Lock()和Unlock()

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/688846.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

拥抱生态农业，享受绿色生活

拥抱生态农业，享受绿色生活

随着人们对健康生活的追求日益增强&#xff0c;生态农业逐渐成为人们关注的焦点。我们深知生态农业对于保护生态环境、提高农产品品质的重要性&#xff0c;因此&#xff0c;我们积极推广生态农业理念&#xff0c;让更多的人了解并参与到生态农业的实践中来。 生态农业的蓝总说&…
阅读更多...
[消息队列 Kafka] Kafka 架构组件及其特性（二）Producer原理

[消息队列 Kafka] Kafka 架构组件及其特性（二）Producer原理

这边整理下Kafka三大主要组件Producer原理。 目录 一、Producer发送消息源码流程 二、ACK应答机制和ISR机制 1&#xff09;ACK应答机制 2&#xff09;ISR机制 三、消息的幂等性 四、Kafka生产者事务 一、Producer发送消息源码流程 Producer发送消息流程如上图。主要是用…
阅读更多...
flask招聘数据分析及展示平台-计算机毕业设计源码39292

flask招聘数据分析及展示平台-计算机毕业设计源码39292

目 录 摘要 1 绪论 1.1研究意义 1.2国内外研究进展 1.3flask框架介绍 2 1.4论文结构与章节安排 3 2 招聘数据分析及展示平台分析 4 2.1 可行性分析 4 2.2 系统流程分析 4 2.2.1数据增加流程 5 2.3.2数据修改流程 5 2.3.3数据删除流程 5 2.3 系统功能分析 5 2.3.1 功能性分…
阅读更多...
Nginx 配置防护 缓慢的 HTTP拒绝服务攻击+点击劫持：X-Frame-Options未配置

Nginx 配置防护 缓慢的 HTTP拒绝服务攻击+点击劫持：X-Frame-Options未配置

一 安全团队检测网站 1 检测到目标主机可能存在缓慢的HTTP拒绝服务攻击 缓慢的HTTP拒绝服务攻击是一种专门针对于Web的应用层拒绝服务攻击&#xff0c;攻击者操纵网络,对目标Web服务器进行海量HTTP请求攻击&#xff0c;直到服务器带宽被打满&#xff0c;造成了拒绝服务。 慢…
阅读更多...
覆盖路径规划经典算法 The Boustrophedon Cellular Decomposition 详解

覆盖路径规划经典算法 The Boustrophedon Cellular Decomposition 详解

2000年一篇论文 Coverage of Known Spaces: The Boustrophedon Cellular Decomposition 横空出世&#xff0c;解决了很多计算机和机器人领域的覆盖路径问题&#xff0c;今天我来详细解读这个算法。 The Boustrophedon Cellular Decomposition 算法详解 这篇论文标题为"C…
阅读更多...
使用智谱 GLM-4-9B 和 SiliconCloud 云服务快速构建一个编码类智能体应用

使用智谱 GLM-4-9B 和 SiliconCloud 云服务快速构建一个编码类智能体应用

本篇文章我将介绍使用智谱 AI 最新开源的 GLM-4-9B 模型和 GenAI 云服务 SiliconCloud 快速构建一个 RAG 应用&#xff0c;首先我会详细介绍下 GLM-4-9B 模型的能力情况和开源限制&#xff0c;以及 SiliconCloud 的使用介绍&#xff0c;最后构建一个编码类智能体应用作为测试。…
阅读更多...
5 分钟内构建一个简单的基于 Python 的 GAN

5 分钟内构建一个简单的基于 Python 的 GAN

文章目录 一、说明二、代码三、训练四、后记 一、说明 生成对抗网络&#xff08;GAN&#xff09;因其能力而在学术界引起轩然大波。机器能够创作出新颖、富有灵感的作品&#xff0c;这让每个人都感到敬畏和恐惧。因此&#xff0c;人们开始好奇&#xff0c;如何构建一个这样的网…
阅读更多...
混合关键性系统技术【同构异构】【SMP、AMP、BMP】【嵌入式虚拟化】

混合关键性系统技术【同构异构】【SMP、AMP、BMP】【嵌入式虚拟化】

混合关键性系统技术【同构异构】【SMP、AMP、BMP】【嵌入式虚拟化】 1 介绍1.1 概述openEuler Embedded 的运行模式openEuler Embedded 混合关键性系统技术架构UniProton 1.2 同构异构区别 【硬件侧】1.3 系统架构【SMP、AMP、BMP】多核处理器平台的系统架构 【软件侧】【SMP、…
阅读更多...
inflight 守恒和带宽资源守恒的有效性

inflight 守恒和带宽资源守恒的有效性

接着昨天的问题&#xff0c;inflight 守恒的模型一定存在稳定点吗&#xff1f;并不是。如果相互抑制强度大于自我抑制强度&#xff0c;系统也会跑飞&#xff1a; 模拟结果如下&#xff1a; 所以一定要记得 a < b。 比对前两个图和后两个图的 a&#xff0c;b 参数关系&am…
阅读更多...
Docker镜像加载原理(Union文件系统)

Docker镜像加载原理(Union文件系统)

联合文件系统 Union文件系统&#xff0c;是一种轻量级的分层高性能服务系统&#xff0c;支持对文件系统的修改来进行一层一层的叠加&#xff0c;同时将不同目录挂载到同一个虚拟文件系统中&#xff0c;Union文件系统是Docker镜像的基础&#xff0c;通过分层来进行集成&am…
阅读更多...
代驾公司在市场竞争中如何保持优势？

代驾公司在市场竞争中如何保持优势？

在竞争激烈的市场中&#xff0c;代驾公司可以通过多种策略保持其竞争优势&#xff0c;包括利用市场潜力、创新服务模式、提高服务效率以及加强品牌建设等。以下是具体的策略&#xff1a; 利用市场潜力 汽车产业空间巨大&#xff1a;随着汽车保有量的增加&#xff0c;代驾行业…
阅读更多...
【ARFoundation自学04】AR Tracked Image 图像追踪识别

【ARFoundation自学04】AR Tracked Image 图像追踪识别

图像识别是很常用的AR功能&#xff01;AR foundation 可以帮助我们轻松实现&#xff01; 1.安装插件 首先还是在资源包中导入ARfoundation 。然后搭建基本的AR ARFoundation框架&#xff01; 2.创建AR session 和XR origin结构&#xff01; 3.然后在XR Origin 物体身上添加A…
阅读更多...
继承-进阶

继承-进阶

父子类成员共享 普通成员对象/父子间不共享&#xff0c; 成员独立 函数成员共享&#xff08;函数不存储在对象中&#xff09; 子类由两部分构成&#xff1a;父类中继承的成员和子类中新定义成员 继承方式 子类中存在父类private成员但不可直接访问&#xff08;及时在类中&am…
阅读更多...
Istio_1.17.8安装

Istio_1.17.8安装

项目背景 按照istio官网的命令一路安装下来&#xff0c;安装好的istio版本为目前的最新版本&#xff0c;1.22.0。而我的k8s集群的版本并不支持istio_1.22的版本&#xff0c;导致ingress-gate网关安装不上&#xff0c;再仔细查看istio的发布文档&#xff0c;如果用istio_1.22版本…
阅读更多...
链表题目练习----重排链表

链表题目练习----重排链表

这道题会联系到前面写的一篇文章----快慢指针相关经典问题。 重排链表 指针法 这道题乍一看&#xff0c;好像有点难处理&#xff0c;但如果仔细观察就会发现&#xff0c;这道题是查找中间节点反转链表链表的合并问题&#xff0c;具体细节有些不同&#xff0c;这个在反装中间链…
阅读更多...
Linux守护进程揭秘-无声无息运行在后台

Linux守护进程揭秘-无声无息运行在后台

在Linux系统中&#xff0c;有一些特殊的进程悄无声息地运行在后台&#xff0c;如同坚实的基石支撑着整个系统的运转。它们就是众所周知的守护进程(Daemon)。本文将为你揭开守护进程的神秘面纱&#xff0c;探讨它们的本质特征、创建过程&#xff0c;以及如何重定向它们的输入输出…
阅读更多...
有待挖掘的金矿：大模型的幻觉之境

有待挖掘的金矿：大模型的幻觉之境

人工智能正在迅速变得无处不在&#xff0c;在科学和学术研究中&#xff0c;自回归的大型语言模型&#xff08;LLM&#xff09;走在了前列。自从LLM的概念被整合到自然语言处理&#xff08;NLP&#xff09;的讨论中以来&#xff0c;LLM中的幻觉现象一直被广泛视为一个显著的社会…
阅读更多...
记录汇川：红绿灯与HMI-ST

记录汇川：红绿灯与HMI-ST

项目要求&#xff1a; 子程序&#xff1a; 子程序&#xff1a; 实际动作如下&#xff1a; 红绿灯与HMI-ST
阅读更多...
电赛报告书写

电赛报告书写

一、总体要求 &#xff08;1&#xff09;摘要&#xff1a;一页&#xff0c;小于300字 &#xff08;2&#xff09;正文&#xff1a;不超过8页 &#xff08;3&#xff09;附录&#xff1a;可以没有&#xff0c;但是不能超过2页 二、摘要书写 摘要要小于等于300字&#xff0c…
阅读更多...
牛客java基础(一)

牛客java基础(一)

A 解析 : java源程序只允许一个public类存在 &#xff0c;且与文件名同名 ; D hashCode方法本质就是一个哈希函数&#xff0c;这是Object类的作者说明的。Object类的作者在注释的最后一段的括号中写道&#xff1a;将对象的地址值映射为integer类型的哈希值。但hashCode()并不…
阅读更多...
最新文章

Copyright @ 2022~2023