04｜ Mutex：骇客编程，如何拓展额外功能？

老师您好，在获取等待者数量的代码中 如果要加上锁持有者的数量的话，为什么不是 v = v >> mutexWaiterShift + (v & mutexLocked) 而是 v = v >> mutexWaiterShift //得到等待者的数值 v = v + (v & mutexLocked) //再加上锁持有者的数量，0或者1 这样呢？第一步修改了 v 的值，v 的第一位已经不再是记录该锁是否被持有了，那 v&mutexLocked 是不是不对呢？

如果底层 Mutex 的 state 在某个版本中含义变了，上边写的 TryLock 和监控锁的一些方法就会失效，所以这样做是不是比较危险。

请教一个基础问题，为啥 (*int32)(unsafe.Pointer(&m.Mutex)) 可以获取sync.Mutex中state的值，Mutex结构中不是还有sema吗？

1）『获取等待者的数量等指标』小节，『第 15 行我们左移三位（这里的常量 mutexWaiterShift 的值为 3）』应该是右移三位。 2）在now～now+timout内，间隔重试调用TryLock

你可以为 Mutex 获取锁时加上 Timeout 机制吗？会有什么问题吗？ 如果加上timeout机制，就不要用defer 去unlock，因为需要自行判断超时时间，然后直接unlock，如果defer再unlock就会触发panic

关于 RWLock 的扩展，我这边给出一段代码（评论不好贴代码，贴个 share link） https://go.dev/play/p/X4YNwqZR4ta ```go package sync import ( "sync" "sync/atomic" "unsafe" ) type RWMutex struct { rw sync.RWMutex } const ( mutexLocked = 1 << iota mutexWake mutexStarving mutexWaiterShift = iota ) const ( rwmutexMaxReaders = 1 << 30 ) func (e *RWMutex) TryLock() bool { if e.GetReader() < 0 { return false } e.rw.Lock() return true } // readerCount > 0 => Reader Hold without Writer, <0 => Reader Hold and Writer waiting, ==0 => no reader // state.mutexLocked == 1 => Writer Hold (in the meanwhile, readerWaiter==0, all reader(readerCount) are waiting) func (e *RWMutex) IsLocked() bool { return e.IsWriterLocked() || e.IsReaderLocked() } func (e *RWMutex) IsWriterLocked() bool { state := atomic.LoadInt32((*int32)(unsafe.Pointer(&e.rw))) return state&mutexLocked == mutexLocked } func (e *RWMutex) IsReaderLocked() bool { return atomic.LoadInt32(e.readerCountPtr()) != 0 } func (e *RWMutex) HasWriter() bool { return atomic.LoadInt32(e.readerCountPtr()) < 0 } func (e *RWMutex) GetWriter() int32 { state := atomic.LoadInt32((*int32)(unsafe.Pointer(&e.rw))) return int32((state >> mutexWaiterShift) + (state & mutexLocked)) } func (e *RWMutex) HasReader() bool { return atomic.LoadInt32(e.readerCountPtr()) != 0 } func (e *RWMutex) GetReader() int32 { r := atomic.LoadInt32(e.readerCountPtr()) if r < 0 { r += rwmutexMaxReaders } return r } func (e *RWMutex) readerCountPtr() *int32 { return (*int32)(unsafe.Pointer(uintptr(unsafe.Pointer(&e.rw)) + unsafe.Sizeof(sync.Mutex{}) + unsafe.Sizeof(uint32(0))*2)) } func (e *RWMutex) readerWaitPtr() *int32 { return (*int32)(unsafe.Pointer(uintptr(unsafe.Pointer(&e.rw)) + unsafe.Sizeof(sync.Mutex{}) + unsafe.Sizeof(uint32(0))*2 + unsafe.Sizeof((int32(0))))) } ```

fast path执行失败，直接返回false不就行了，为啥还要往下执行？正常不是多个携程并发只有一个执行成功，其他都是失败么？

想问一下，为什么最后实现线程安全的队列里面的 Dequeue() 方法释放锁不用defer，这样不用写两次unlock

老师您好， // 如果能成功抢到锁 if atomic.CompareAndSwapInt32((*int32)(unsafe.Pointer(&m.Mutex)), 0, mutexLocked) { return true } 在以上代码中，(*int32)(unsafe.Pointer(&m.Mutex))是取的Mutex中state的首地址对嘛?

func (m *Mutex) TryLock() bool { // 如果能成功抢到锁 if atomic.CompareAndSwapInt32((*int32)(unsafe.Pointer(&m.Mutex)), 0, mutexLocked) { return true } // 如果处于唤醒、加锁或者饥饿状态，这次请求就不参与竞争了，返回false old := atomic.LoadInt32((*int32)(unsafe.Pointer(&m.Mutex))) fmt.Println("===old===:", old) if old&(mutexLocked|mutexStarving|mutexWoken) != 0 { return false } // 尝试在竞争的状态下请求锁 new := old | mutexLocked fmt.Println("===new===:", new) //请问在什么情况下会执行到这里 return atomic.CompareAndSwapInt32((*int32)(unsafe.Pointer(&m.Mutex)), old, new) } func main() { var mu Mutex go func() { // 启动一个goroutine持有一段时间的锁 mu.Lock() time.Sleep(time.Duration(rand.Intn(2)) * time.Second) mu.Unlock() }() time.Sleep(time.Second) n := int(10) var wg sync.WaitGroup wg.Add(n) for i := 0; i < n; i++ { go func() { ok := mu.TryLock() // 尝试获取到锁 defer wg.Done() if ok { // 获取成功 fmt.Println("got the lock") // do something mu.Unlock() return } }() } // 没有获取到 wg.Wait() } 老师，你好。在main中尝试编写一段逻辑测试TryLock方法，请问在什么情况下会执行fmt.Println("===new===:", new) 请老师答疑解惑，谢谢。