条件锁
type Cond struct {
L Locker
notify notifyList
}
type notifyList struct {
wait uint32 //表示当前 Wait 的最大 ticket 值
notify uint32 //表示目前已唤醒的 goroutine 的 ticket 的最大值
lock uintptr // key field of the mutex
head unsafe.Pointer //链表头
tail unsafe.Pointer //链表尾
}
相关函数
func (c *Cond) Wait() {
// 获取当前ticket，即wait的值，实际是atomic.Xadd(&l.wait, 1) - 1，这样wait原子加1,
t := runtime_notifyListAdd(&c.notify)
// 注意这里，必须先解锁，因为 runtime_notifyListWait 要切走 goroutine
// 所以这里要解锁，要不然其他 goroutine 没法获取到锁了
//功能是将当前 goroutine 插入到 notifyList 链表
c.L.Unlock()
runtime_notifyListWait(&c.notify, t)
// 这里已经唤醒了，因此需要再度锁上
c.L.Lock()
}
func (c *Cond) Signal() {
runtime_notifyListNotifyOne(&c.notify)
}
//notifyList 是一个链表结构，我们为何不直接取链表最头部唤醒呢
//因为 notifyList 会有乱序的可能，获取 ticket 和加入 notifyList
//是两个独立的行为，并发操作有可能的乱序，大部分场景下比较一两次之后就会很快停止
func notifyListNotifyOne(l *notifyList) {
***
for p, s := (*sudog)(nil), l.head; s != nil; p, s = s, s.next {
if s.ticket == t {
n := s.next
if p != nil {
p.next = n
} else {
l.head = n
}
if n == nil {
l.tail = p
}
s.next = nil
return
}
}
***
}
func (c *Cond) Broadcast() {
runtime_notifyListNotifyAll(&c.notify)
}
//唤醒所有等待的goruntine
fuc notifyListNotifyAll(l *notifyList) {
// Go through the local list and ready all waiters.
for s != nil {
next := s.next
s.next = nil
readyWithTime(s, 4)
s = next
}
}
互斥锁 mutex
自旋：新goroutine或被唤醒的goroutine首次获取不到锁，就会自旋（spin，通过循环不断尝试，在runtime实现的）的方式尝试检查锁，不需要上下文切换，提供性能。
饥饿模式：高并发情况下，新来的g一直自旋，waiter可能悲剧地获取不到锁。故waiter获取不到锁的时间超过阈值1毫秒，它会被插入到队列的前面，这个Mutex进入饥饿模式。
在饥饿模式下，Mutex的拥有者将直接把锁交给队列最前面的waiter。新的g不会尝试获取锁，不抢也不spin，乖乖地加入到等待队列的尾部。
如果拥有Mutex的waiter发现下面两种情况的其中之一，它就会把这个Mutex转换成正常模式:
- 此waiter已经是队列中的最后一个waiter了，没有其它的等待锁的goroutine了；
- 此waiter的等待时间小于1毫秒。
// A Locker represents an object that can be locked and unlocked.
type Locker interface { //锁接口
Lock()
Unlock()
}
type Mutex struct {//互斥锁实例
state int32 //状态
sema uint32 //信号量
}
const (
mutexLocked = 1 << iota //0x0000 0001
mutexWoken //0x0000 0010
mutexStarving //0x0000 0100
mutexWaiterShift = iota 3 //等待者数量的标志,最多可以阻塞2^29个goroutine。
starvationThresholdNs = 1e6
)
mutexLocked代表锁的状态，如果为1代表已加锁
mutexWoken代表是否唤醒，如果为 1代表已唤醒
mutexStarving代表是否处于饥饿模式，如果为1 代表是
mutexWaiterShift 值是3，有人会问这里为什么不左移，而是直接是3，这是因为3这个会有1<<mutexWaiterShift代表1个waiter数量，也有右移代表获取mutex上面的waiter数量。
starvationThresholdNs代表判断饥饿模式的时间，如果等待时间超过这个时间就判断为饥饿
func (m *Mutex) Lock() {
// Slow path (outlined so that the fast path can be inlined)
m.lockSlow() //补贴源码，看图了
}
解锁，别贴代码，上图
读写锁
type RWMutex struct {
w Mutex
writerSem uint32 // 用于writer等待，wait读完成排队的信号量
readerSem uint32 // 用于reader等待，wait写完成排队的信号量
readerCount atomic.Int32 // 读锁的计数器
readerWait atomic.Int32 // 有写锁时，等待读锁释放的数量
}
const rwmutexMaxReaders = 1 << 30 //go支持的最高加读锁的数量
func (rw *RWMutex) RLock() {
// reader计数器+1
// 如果小于0则表明有写锁在占有
if rw.readerCount.Add(1) < 0 {
// 等待写锁释放，
runtime_SemacquireRWMutexR(&rw.readerSem, false, 0)
}
}
func (rw *RWMutex) RUnlock() {
// reader计数器-1，
// 如果小于0，说明有读锁在等待
if r := rw.readerCount.Add(-1); r < 0 {
rw.rUnlockSlow(r)
}
}
func (rw *RWMutex) rUnlockSlow(r int32) {
// 等待的读书数量-1，等于0说明已经没有等待的读锁
if rw.readerWait.Add(-1) == 0 {
// 最后一名读锁了，唤醒写锁
runtime_Semrelease(&rw.writerSem, false, 1)
}
}
func (rw *RWMutex) Lock() {
// 与写锁竞争，获取互斥锁
rw.w.Lock()
// 把readerCount- rwmutexMaxReaders，表示有写锁
r := rw.readerCount.Add(-rwmutexMaxReaders) + rwmutexMaxReaders
// 等待读锁数量readerwait+readerCount的数量，等待读锁完成.
if r != 0 && rw.readerWait.Add(r) != 0 {
//等待写锁信号量
runtime_SemacquireRWMutex(&rw.writerSem, false, 0)
}
}
func (rw *RWMutex) Unlock() {
// 告诉读锁，写锁已完成，可以读了.
r := rw.readerCount.Add(rwmutexMaxReaders)
//唤醒所有读锁
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// 允许其他写锁获取锁
rw.w.Unlock()
}
