[Golang并发]Sync.Mutex

news/2024/9/28 21:36:49

源码

// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.// Package sync provides basic synchronization primitives such as mutual
// exclusion locks. Other than the [Once] and [WaitGroup] types, most are intended
// for use by low-level library routines. Higher-level synchronization is
// better done via channels and communication.
//
// Values containing the types defined in this package should not be copied.
package syncimport ("internal/race""sync/atomic""unsafe"
)// Provided by runtime via linkname.
func throw(string)
func fatal(string)// A Mutex is a mutual exclusion lock.
// The zero value for a Mutex is an unlocked mutex.
//
// A Mutex must not be copied after first use.
//
// In the terminology of [the Go memory model],
// the n'th call to [Mutex.Unlock] “synchronizes before” the m'th call to [Mutex.Lock]
// for any n < m.
// A successful call to [Mutex.TryLock] is equivalent to a call to Lock.
// A failed call to TryLock does not establish any “synchronizes before”
// relation at all.
//
// [the Go memory model]: https://go.dev/ref/mem
type Mutex struct {state int32sema  uint32
}// A Locker represents an object that can be locked and unlocked.
type Locker interface {Lock()Unlock()
}const (mutexLocked = 1 << iota // mutex is locked 001mutexWoken              // 010mutexStarving           // 100mutexWaiterShift = iota // 3// Mutex fairness.//// Mutex can be in 2 modes of operations: normal and starvation.// In normal mode waiters are queued in FIFO order, but a woken up waiter// does not own the mutex and competes with new arriving goroutines over// the ownership. New arriving goroutines have an advantage -- they are// already running on CPU and there can be lots of them, so a woken up// waiter has good chances of losing. In such case it is queued at front// of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,// it switches mutex to the starvation mode.//// In starvation mode ownership of the mutex is directly handed off from// the unlocking goroutine to the waiter at the front of the queue.// New arriving goroutines don't try to acquire the mutex even if it appears// to be unlocked, and don't try to spin. Instead they queue themselves at// the tail of the wait queue.//// If a waiter receives ownership of the mutex and sees that either// (1) it is the last waiter in the queue, or (2) it waited for less than 1 ms,// it switches mutex back to normal operation mode.//// Normal mode has considerably better performance as a goroutine can acquire// a mutex several times in a row even if there are blocked waiters.// Starvation mode is important to prevent pathological cases of tail latency.starvationThresholdNs = 1e6
)// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock() {// Fast path: grab unlocked mutex.if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {if race.Enabled {race.Acquire(unsafe.Pointer(m))}return}// Slow path (outlined so that the fast path can be inlined)m.lockSlow()
}// TryLock tries to lock m and reports whether it succeeded.
//
// Note that while correct uses of TryLock do exist, they are rare,
// and use of TryLock is often a sign of a deeper problem
// in a particular use of mutexes.
func (m *Mutex) TryLock() bool {old := m.stateif old&(mutexLocked|mutexStarving) != 0 {return false}// There may be a goroutine waiting for the mutex, but we are// running now and can try to grab the mutex before that// goroutine wakes up.if !atomic.CompareAndSwapInt32(&m.state, old, old|mutexLocked) {return false}if race.Enabled {race.Acquire(unsafe.Pointer(m))}return true
}func (m *Mutex) lockSlow() {var waitStartTime int64starving := falseawoke := falseiter := 0old := m.statefor {// Don't spin in starvation mode, ownership is handed off to waiters// so we won't be able to acquire the mutex anyway.if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {// Active spinning makes sense.// Try to set mutexWoken flag to inform Unlock// to not wake other blocked goroutines.if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {awoke = true}runtime_doSpin()iter++old = m.statecontinue}new := old// Don't try to acquire starving mutex, new arriving goroutines must queue.if old&mutexStarving == 0 {new |= mutexLocked}if old&(mutexLocked|mutexStarving) != 0 {new += 1 << mutexWaiterShift}// The current goroutine switches mutex to starvation mode.// But if the mutex is currently unlocked, don't do the switch.// Unlock expects that starving mutex has waiters, which will not// be true in this case.if starving && old&mutexLocked != 0 {new |= mutexStarving}if awoke {// The goroutine has been woken from sleep,// so we need to reset the flag in either case.if new&mutexWoken == 0 {throw("sync: inconsistent mutex state")}new &^= mutexWoken}if atomic.CompareAndSwapInt32(&m.state, old, new) {if old&(mutexLocked|mutexStarving) == 0 {break // locked the mutex with CAS}// If we were already waiting before, queue at the front of the queue.queueLifo := waitStartTime != 0if waitStartTime == 0 {waitStartTime = runtime_nanotime()}runtime_SemacquireMutex(&m.sema, queueLifo, 1)starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNsold = m.stateif old&mutexStarving != 0 {// If this goroutine was woken and mutex is in starvation mode,// ownership was handed off to us but mutex is in somewhat// inconsistent state: mutexLocked is not set and we are still// accounted as waiter. Fix that.if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {throw("sync: inconsistent mutex state")}delta := int32(mutexLocked - 1<<mutexWaiterShift)if !starving || old>>mutexWaiterShift == 1 {// Exit starvation mode.// Critical to do it here and consider wait time.// Starvation mode is so inefficient, that two goroutines// can go lock-step infinitely once they switch mutex// to starvation mode.delta -= mutexStarving}atomic.AddInt32(&m.state, delta)break}awoke = trueiter = 0} else {old = m.state}}if race.Enabled {race.Acquire(unsafe.Pointer(m))}
}// Unlock unlocks m.
// It is a run-time error if m is not locked on entry to Unlock.
//
// A locked [Mutex] is not associated with a particular goroutine.
// It is allowed for one goroutine to lock a Mutex and then
// arrange for another goroutine to unlock it.
func (m *Mutex) Unlock() {if race.Enabled {_ = m.staterace.Release(unsafe.Pointer(m))}// Fast path: drop lock bit.new := atomic.AddInt32(&m.state, -mutexLocked)if new != 0 {// Outlined slow path to allow inlining the fast path.// To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock.m.unlockSlow(new)}
}func (m *Mutex) unlockSlow(new int32) {if (new+mutexLocked)&mutexLocked == 0 {fatal("sync: unlock of unlocked mutex")}if new&mutexStarving == 0 {old := newfor {// If there are no waiters or a goroutine has already// been woken or grabbed the lock, no need to wake anyone.// In starvation mode ownership is directly handed off from unlocking// goroutine to the next waiter. We are not part of this chain,// since we did not observe mutexStarving when we unlocked the mutex above.// So get off the way.if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {return}// Grab the right to wake someone.new = (old - 1<<mutexWaiterShift) | mutexWokenif atomic.CompareAndSwapInt32(&m.state, old, new) {runtime_Semrelease(&m.sema, false, 1)return}old = m.state}} else {// Starving mode: handoff mutex ownership to the next waiter, and yield// our time slice so that the next waiter can start to run immediately.// Note: mutexLocked is not set, the waiter will set it after wakeup.// But mutex is still considered locked if mutexStarving is set,// so new coming goroutines won't acquire it.runtime_Semrelease(&m.sema, true, 1)}
}

源码详解

mutex结构

type Mutex struct {state int32sema  uint32
}

Sync.Mutex由两个字段构成,state用来表示当前互斥锁处于的状态,sema用于控制锁状态的信号量

互斥锁state(32bit)主要记录了如下四种状态:

  • waiter_num(29bit):记录了当前等待这个锁的goroutine数量
  • starving(1bit):当前锁是否处于饥饿状态,0: 正常状态 1: 饥饿状态
  • woken(1bit):当前锁是否有goroutine已被唤醒。 0:没有goroutine被唤醒; 1: 有goroutine正在加锁过程
    Woken 状态用于加锁和解锁过程的通信,例如,同一时刻,两个协程一个在加锁,一个在解锁,在加锁的协程可能在自旋过程中,此时把 Woken 标记为 1,用于通知解锁协程不必释放信号量了。
  • locked(1bit):当前锁是否被goroutine持有。 0: 未被持有 1: 已被持有

sema信号量的作用:当持有锁的gorouine释放锁后,会释放sema信号量,这个信号量会唤醒之前抢锁阻塞的gorouine来获取锁。

自旋

自旋过程是指,goroutine尝试加锁时,如果当前 Locked 位为 1,则说明该锁当前是由其他协程持有,尝试加锁的协程并不会马上转入阻塞队列,而是会持续的探测 Locked 位是否变为 0。自旋的时间很短,但如果在自旋过程中发现锁已被释放,那么协程可以立即获取锁。此时即便有协程被唤醒也无法获取锁,只能再次阻塞,这个可不是我们想要的。
自旋的好处是,当加锁失败时不必立即转入阻塞,有一定机会获取到锁,这样可以避免协程的切换。但是自旋会导致阻塞队列中的goroutine一直获取不到锁,处于饥饿状态

自旋必须满足以下所有条件:

  • 自旋的次数要足够小,通常为4,即「自旋最多为4次」
  • CPU 核数要大于1,否则自旋是没有意义的,因为此时不可能有其他协程释放锁
  • 协程调度机制中的 Process 数量要大于 1,比如使用 GOMAXPROCS() 将处理器设置为 1 就不能启用自旋
  • 协程调度机制中的可运行队列必须为空,否则会延迟协程调度

为了避免协程长时间无法获取锁,自1.8版本以来增加了一个状态,即 Mutex 的 Starving 状态。这个状态下不会自旋,而是直接进入阻塞队列,一旦有协程释放锁,那么一定会唤醒一个阻塞队列中的协程并成功加锁。

常量

const (mutexLocked = 1 << iota // mutex is locked 001mutexWoken              // 010mutexStarving           // 100mutexWaiterShift = iota // 3starvationThresholdNs = 1e6
)

首先,iota 是Go语言中的一个预定义标识符,用于在常量声明中生成连续的整数值。它的初始值为0,并且每次在常量声明中使用时都会自动递增。
在这段代码中,首先定义了 mutexLocked 常量,它的值是 1 << iota,即 1 左移 0 位,结果仍然是 1。因此,mutexLocked 的值是 1,代表互斥锁被锁定。
接下来,mutexWoken 的值是 1 << iota,即 1 左移 1 位,结果是 2。因此,mutexWoken 的值是 2,代表互斥锁被唤醒。
然后,mutexStarving 的值是 1 << iota,即 1 左移 2 位,结果是 4。因此,mutexStarving 的值是 4,代表互斥锁出现饥饿状态。
最后,mutexWaiterShift = iota 将 iota 的值赋给 mutexWaiterShift,此时 iota 的值为 3。因此,mutexWaiterShift 的值是 3。
综上所述,这段代码定义了互斥锁的不同状态的常量值,分别是 1(锁定)、2(唤醒)、4(饥饿),并且将 iota 的值 3 赋给了 mutexWaiterShift。

常量池中还包含这样一段注释,让我们翻译一下

// Mutex fairness.
//
// Mutex can be in 2 modes of operations: normal and starvation.
// In normal mode waiters are queued in FIFO order, but a woken up waiter
// does not own the mutex and competes with new arriving goroutines over
// the ownership. New arriving goroutines have an advantage -- they are
// already running on CPU and there can be lots of them, so a woken up
// waiter has good chances of losing. In such case it is queued at front
// of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,
// it switches mutex to the starvation mode.
//
// In starvation mode ownership of the mutex is directly handed off from
// the unlocking goroutine to the waiter at the front of the queue.
// New arriving goroutines don't try to acquire the mutex even if it appears
// to be unlocked, and don't try to spin. Instead they queue themselves at
// the tail of the wait queue.
//
// If a waiter receives ownership of the mutex and sees that either
// (1) it is the last waiter in the queue, or (2) it waited for less than 1 ms,
// it switches mutex back to normal operation mode.
//
// Normal mode has considerably better performance as a goroutine can acquire
// a mutex several times in a row even if there are blocked waiters.
// Starvation mode is important to prevent pathological cases of tail latency.

互斥公平性。

互斥可以有两种操作模式:正常和饥饿。
在正常模式下,等待者按 FIFO 顺序排队,但唤醒的等待者不拥有互斥,并与新到达的 goroutine 争夺所有权。新到达的 goroutine 具有优势——它们已经在 CPU 上运行,并且可能有很多,因此唤醒的等待者很有可能失败。在这种情况下,它会排在等待队列的前面。如果等待者超过 1 毫秒无法获取互斥,它会将互斥切换到饥饿模式。

在饥饿模式下,互斥的所有权直接从解锁的 goroutine 移交给队列前面的等待者。新到达的 goroutine 不会尝试获取互斥,即使它似乎已被解锁,也不会尝试旋转。相反,它们将自己排在等待队列的末尾。

如果等待者获得互斥锁的所有权并发现
(1) 它是队列中的最后一个等待者,或者 (2) 它等待的时间少于 1 毫秒,
它会将互斥锁切换回正常操作模式。

正常模式的性能要好得多,因为即使有阻塞的等待者,goroutine 也可以连续多次获取互斥锁。
饥饿模式对于防止尾部延迟的情况非常重要(即避免饥饿)。

old & (mutexLocked | mutexStarving)

old & (mutexLocked | mutexStarving) 使用按位与操作符(&)检查 old 是否处于 mutexLockedmutexStarving 状态。这里的 mutexLockedmutexStarving 都是 2 的幂,因此它们在二进制表示中只有一个位为 1。这使得我们可以在一个整数值中存储和检查多个这样的标记。

  1. 首先,使用按位或操作符(|)将 mutexLockedmutexStarving 进行按位或操作。结果是一个整数值,其二进制表示中的第 1 位和第 3 位都为 1(即 0101,十进制为 5)。
  2. 接下来,使用按位与操作符(&)将 old 与上一步的结果相与。这个操作会将 old 的二进制表示与 0101 进行按位与操作,即比较 old 中的第 1 位和第 3 位是否为 1。
  3. 如果第 1 位或第 3 位为 1,那么结果将不为零,表示 old 具有 mutexLockedmutexStarving 状态标记。只要具有其中一个标记,结果都将不为0

通过这个表达式,我们可以快速地检查整数值 old 是否同时具有 mutexLockedmutexStarving 这两个状态标记,从而了解互斥锁的当前状态。这是一种高效的位操作技巧,可以节省内存空间,并提高代码执行速度。

Lock

func (m *Mutex) Lock() {// 这里首先尝试直接上锁// 当mutex不处在locked状态时,尝试直接上锁,也就是将locked位修改为1if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {// 这里记录了获取锁的操作,暂时不用管if race.Enabled {race.Acquire(unsafe.Pointer(m))}// 获取锁成功,直接返回return}// Slow path (outlined so that the fast path can be inlined)// 如果上面的获取过程没有成功,说明mutex已经被锁定,走slowm.lockSlow()
}
func (m *Mutex) lockSlow() {var waitStartTime int64starving := false// awoke用来跟踪当前的 goroutine 是否已经成功设置了 mutexWoken 标志,即是否已经通知 Unlock 不要唤醒其他被阻塞的 goroutine。awoke := false// 自旋次数iter := 0// 获取mutex的状态old := m.statefor {// Don't spin in starvation mode, ownership is handed off to waiters// so we won't be able to acquire the mutex anyway.// 这里的操作很精妙,old&(mutexLocked|mutexStarving) == mutexLocked// 这个操作要求old&(101) == 001也就是old在mutexLocked位上必须为1,在mutexStarving位上必须为0,// 即,处在锁定但不饥饿状态,饥饿状态下不允许自旋。// runtime_canSpin(iter)是另一些条件,包括多核、压力不大并且在一定次数内可以自旋if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {// Active spinning makes sense.// Try to set mutexWoken flag to inform Unlock// to not wake other blocked goroutines.// !awoke没有成功设置mutexWoken// old&mutexWoken == 0,mutex锁没有设置woken位// old>>mutexWaiterShift != 0没有等待线程// atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken)成功设置woken位// awoke = true当前线程已成功设置mutexWoken位if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {awoke = true}// 自旋runtime_doSpin()// 自旋次数iter++old = m.statecontinue}// 1. 锁仍被锁定,处于正常状态// 2. 锁仍被锁定,处于饥饿状态// 3. 锁被释放,处于正常状态// 4. 锁被释放,处于饥饿状态new := old// Don't try to acquire starving mutex, new arriving goroutines must queue.// 如果old状态不是饥饿状态,设置new为锁定状态if old&mutexStarving == 0 {new |= mutexLocked}// 锁定或饥饿if old&(mutexLocked|mutexStarving) != 0 {new += 1 << mutexWaiterShift}// The current goroutine switches mutex to starvation mode.// But if the mutex is currently unlocked, don't do the switch.// Unlock expects that starving mutex has waiters, which will not// be true in this case.if starving && old&mutexLocked != 0 {new |= mutexStarving}if awoke {// The goroutine has been woken from sleep,// so we need to reset the flag in either case.if new&mutexWoken == 0 {throw("sync: inconsistent mutex state")}new &^= mutexWoken}if atomic.CompareAndSwapInt32(&m.state, old, new) {if old&(mutexLocked|mutexStarving) == 0 {break // locked the mutex with CAS}// If we were already waiting before, queue at the front of the queue.queueLifo := waitStartTime != 0if waitStartTime == 0 {waitStartTime = runtime_nanotime()}runtime_SemacquireMutex(&m.sema, queueLifo, 1)starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNsold = m.stateif old&mutexStarving != 0 {// If this goroutine was woken and mutex is in starvation mode,// ownership was handed off to us but mutex is in somewhat// inconsistent state: mutexLocked is not set and we are still// accounted as waiter. Fix that.if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {throw("sync: inconsistent mutex state")}delta := int32(mutexLocked - 1<<mutexWaiterShift)if !starving || old>>mutexWaiterShift == 1 {// Exit starvation mode.// Critical to do it here and consider wait time.// Starvation mode is so inefficient, that two goroutines// can go lock-step infinitely once they switch mutex// to starvation mode.delta -= mutexStarving}atomic.AddInt32(&m.state, delta)break}awoke = trueiter = 0} else {old = m.state}}if race.Enabled {race.Acquire(unsafe.Pointer(m))}
}
func sync_runtime_canSpin(i int) bool {if i >= active_spin || ncpu <= 1 || gomaxprocs <= int32(sched.npidle+sched.nmspinning)+1 {return false}if p := getg().m.p.ptr(); !runqempty(p) {return false}return true
}

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

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈,一经查实,立即删除!

相关文章

COLA架构初始化DDD项目

使用COLA脚手架初始化项目 实战代码:https://gitee.com/XuXiaoCong/cola-springboot-demo COLA项目地址:https://github.com/alibaba/COLA BiliBili视频创建项目使用COLA脚手架(Maven)创建COLA项目DgroupId: 公司/组织名称 DartifactId:项目名称 Dversion:版本号 Dpackage:…

试用了下WPS定制版,真香!

告别广告和弹窗!告别广告和弹窗! 前言 现在办公/日常使用基本上都是离不开 office 三件套的了。我个人也曾购买过微软的 office 三件套,WPS 会员版: ​ ‍ ‍ ​ ‍ ‍ 随着消费降级, 使用一段时间后,我发现我根本用不上什么高级的功能,感觉不划算,几百块钱下馆子不香吗…

HarmonyOS应用开发——Hello World

下载 HUAWEI DevEco Studio: https://developer.harmonyos.com/cn/develop/deveco-studio/#download同意,进入配置页面:配置下载源以及本地存放路径,包括nodejs和ohpm:配置鸿蒙SDK路径:接受协议:确认无误后,点击下一步,开始自动下载有关环境以及依赖:全部下载完成,点击…

发文指南 | 生信植物科学类期刊近五年影响因子分享

前几天(2024.6.20)科睿唯安发布了《期刊引证报告》,公开2023年期刊最新影响因子。本号对植物科学领域和农林科学领域期刊做了及时分享:重磅出炉!2024植物科学领域&农林科学领域期刊影响因子 参与本号运营的小伙伴们基本都是生物信息、植物科学类的背景,因此我们对这类…

Grab 基于 Apache Hudi 实现近乎实时的数据分析

介绍 在数据处理领域,数据分析师在数据湖上运行其即席查询。数据湖充当分析和生产环境之间的接口,可防止下游查询影响上游数据引入管道。为了确保数据湖中的数据处理效率,选择合适的存储格式至关重要。 Vanilla数据湖解决方案构建在具有 Hive 元存储的云对象存储之上,其中数…

aspera下载nr数据库

ascp -QT -i ~/.aspera/connect/etc/asperaweb_id_dsa.openssh -l 1000M -k 1 -T anonftp@ftp.ncbi.nlm.nih.gov:/blast/db/nr.00.tar.gz ./

【昆虫识别系统】图像识别Python+卷积神经网络算法+人工智能+深度学习+机器学习+TensorFlow+ResNet50

一、介绍 昆虫识别系统,使用Python作为主要开发语言。通过TensorFlow搭建ResNet50卷积神经网络算法(CNN)模型。通过对10种常见的昆虫图片数据集(蜜蜂, 甲虫, 蝴蝶, 蝉, 蜻蜓, 蚱蜢, 蛾, 蝎子, 蜗牛, 蜘蛛)进行训练,得到一个识别精度较高的H5格式模型文件,然后使用Django…

BookKeeper 介绍(3)--API

本文主要介绍 BookKeeper 的 API,文中所使用到的软件版本:Java 1.8.0_341、BookKeeper 4.16.5。1、引入依赖<dependency><groupId>org.apache.bookkeeper</groupId><artifactId>bookkeeper-server</artifactId><version>4.16.5</vers…