Look at a go1.12.5 in Mutex source:
// 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 sync
import (
"internal/race"
"sync/atomic"
"unsafe"
)
func throw(string) // provided by runtime
// 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.
type Mutex struct {
state int32
sema uint32
}
// A Locker represents an object that can be locked and unlocked.
type Locker interface {
Lock()
Unlock()
}
const (
mutexLocked = 1 << iota // mutex is locked
mutexWoken
mutexStarving
mutexWaiterShift = iota
// 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
}
var waitStartTime int64
starving := false
awoke := false
iter := 0
old := m.state
for {
// 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.state
continue
}
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 != 0
if waitStartTime == 0 {
waitStartTime = runtime_nanotime()
}
runtime_SemacquireMutex(&m.sema, queueLifo)
starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
old = m.state
if 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 = true
iter = 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.state
race.Release(unsafe.Pointer(m))
}
// Fast path: drop lock bit.
new := atomic.AddInt32(&m.state, -mutexLocked)
if (new+mutexLocked)&mutexLocked == 0 {
throw("sync: unlock of unlocked mutex")
}
if new&mutexStarving == 0 {
old := new
for {
// 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) | mutexWoken
if atomic.CompareAndSwapInt32(&m.state, old, new) {
runtime_Semrelease(&m.sema, false)
return
}
old = m.state
}
} else {
// Starving mode: handoff mutex ownership to the next waiter.
// 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)
}
}
Mutex structure
the Mutex {struct type
State Int32 // state mutex
sema uint32 // semaphore coroutine block waiting for the semaphore, coroutine unlocked thereby releasing wakeup semaphore wait semaphore coroutine.
}
Check the information of time to find a good show map Mutex memory layout:
- Locked: Indicates whether the Mutex is locked, 0 represents not locked, 1 representative has been locked.
- Woken: Indicates whether there coroutine has been awakened, 0 for no coroutine to be awakened, represents the existing coroutine to be awakened, is locked.
- Starving: indicates that the Mutex is in a state of hunger, 0 to not hungry, a representative of a state of hunger, that is blocking more than 1ms.
- Waiter: indicates the number coroutine blocked waiting for the lock, when the coroutine to be unlocked if this value to determine whether to release the semaphore.
Coroutine actually grab lock between the right grab Locked assignment, to give the Locked field set, it shows grab lock success. Grab less than a block waiting for the semaphore Mutex.sema, coroutine unlock once holding the lock, waiting to be awakened in turn coroutine.
(Written by this author nice, original link I put the text last ~)
(Sometimes very trance, in the end there is no need to write your own blog, and most of the time the Internet porters, one day, I can write pure original technology blog ~)
Two modes of operation
go mutex has two operating modes: normal mode and starvation mode
In the normal mode, the standby state coroutine (waiters) queued in FIFO order. A awoke the sleeping (sleep) (ready) to co-drive does not own the mutex, and it does not come as a new coroutine advantage for the mutex competition. New arrival coroutine may have been running on the CPU, and the number of possible still too many. However, if the wait were awoke to wait in the queue mutex blocking more than 1 ms, the normal mode will switch to starvation mode.
In the starvation mode, ownership of the mutex lock release directly transferred from the coroutine to wait before the queue's most. New arrival coroutine even have a competitive advantage, not to fight mutex, on the contrary, they will go to the end of the queue waiting in line.
If the person to wait for ownership of the mutex awoke and found that (1) it is the last person waiting in the queue, or (2) it is not waiting for 1ms, it will switch to starvation mode to the normal mode.
A normal mode having a very good performance, because even if there are waiting for blocking coroutine mutex may be acquired a plurality of times continuously.
The starvation mode can prevent delays in processing arriving coroutine (but may be far behind new coroutines), plainly, it is to prevent starvation mode coroutine into starvation busy state like setting.
Both methods
Mutex only provides two methods, namely Lock () Lock and Unlock () to unlock.
Lock
Mutex above goes to memory layout diagram, for example, there is no obstruction of the easiest is to lock Locked set to 1, when the lock is held, it will Waiter ++, coroutines into the obstruction, after the wake-up Locked value becomes 0 .
Unlock
Mutex is still goes above an example memory layout view, there is no other blocking wait coroutine lock (i.e. Waiter is 0), then set to zero as long as the Locked need not release the semaphore. If unlocked, there are one or more blocking coroutine (i.e. Waiter> 0), you need to be set to Locked after 0, release the semaphore wakeup blocking coroutine.
Spin
basic concept
We said above, may be blocked when locked, this time, not immediately enter the coroutine blocked, but will continue to detect whether Locked to 0, the process is the spin (spin) process. runtime_canSpin mutex source code from source () and runtime_doSpin () two methods can be used to determine whether they are spinning (i.e., whether the spin conditions) and performing spin.
Spin it must meet all the conditions:
- Spin small enough number, usually four, i.e., up to 4 times a coroutine each spin.
- CPU core number is greater than 1, or spin does not make sense, because at this time there can be no other coroutines release the lock.
- Process Number coroutine scheduling mechanism is greater than 1, such as using GOMAXPROCS () Sets the processor 1 will not start spinning.
- Coroutine scheduling mechanisms must be run queue is empty, otherwise it will delay coroutine scheduling.
限制自旋次数很好理解，关于CPU核数，一开始我不理解为什么要限制这个，不妨来设想一下协程自旋的场景，假设一个协程主动释放了锁并释放了信号量，我们的协程在对处理器的竞争中惨败，因此进入短暂自旋，以期寻找其他门路，即看看其他处理器是不是正有协程准备解锁，试想，假如只有1核，刚刚在和我们的竞争中获取取得锁控制权的协程，怎么可能在短期内释放锁，因此只能直接进入阻塞。
至于什么是GOMAXPROCS呢？就是逻辑CPU数量，它可以被设置为如下几种数值：
- <1：不修改任何数值。
- =1：单核心执行。
- >1：多核并发执行
一般情况下，可以使用runtime.NumCPU查询CPU数量，并使用runtime.GOMAXPROCS()进行设置，如：runtime.GOMAXPROCS(runtime.NumCPU)，将逻辑CPU数量设置为物理CPU数量。
现在想想，对Process进行限制，是不是显而易见的事。
至于可运行队列为什么必须为空，我的理解，就是当前只能有这一条就绪线程，也就是说同时只能有一条自旋。
自旋的好处
可以更充分的利用CPU。
自旋的坏处
如果协程通过自旋获得锁，那么之前被阻塞的协程将无法获得锁，如果加锁的协程特别多，每次都通过自旋获得锁，那么之前被阻塞的协程将很难获得锁，从而进入饥饿状态。因此，在1.8版本以后，饥饿状态（即Starving为1）下不允许自旋。
补充
自旋和模式切换是有区别的，自旋发生在阻塞之前，模式切换发生在阻塞之后。
整个互斥过程是围绕着Mutex量进行的，即争夺对Mutex内存的修改权，Mutex可以看作是处理器的钥匙，争夺到Mutex的协程可以被处理。
Woken的作用：
Woken用于加锁和解锁过程的通信，譬如，同一时刻，有两个协程，一个在加锁，一个在解锁，在加锁的协程可能在自旋，此时把Woken置为1，通知解锁协程不必释放信号量了。也就是说Woken标志着当前有就绪状态的进程，不用解锁协程去通知。
参考链接
https://my.oschina.net/renhc/blog/2876211
另外还有一篇详解mutex源码的博客：