前回
GoのSync.mutexを内部実装から理解したい（StarvingMode編）

前回、前回とmutexの挙動を見てきましたが、awoke、mutexWokenは飛ばしたままでした、
今回はawokeの役割についてを解説していきます。

まずmutex.goのLockSlowでspinパートがあり、そこでawokeがあったことを思い出します。

mutex.go

	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
		
        省略....
		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
		}

ここで、spinに中のGがawoke=trueとなる条件は、
awoke!=trueかつ、
m.stateがmutexWokenでないかつ、
waiter、待ち人数が一人以上かつ、
CASに成功という条件です。
この条件から読み取れることは、一つのGしかawoke=trueとしたくないという意思です。
G1とそれ以外複数のGがあり、G1がawoke=trueとなったとすると、その時はCASでm.stateにmutexWokenフラグが立っているはずなので、
他のGはawoke=trueとはなりません。
また、waiterが0人の時は誰もawoke=trueとはなりません。

そして、if awokeのところでは新しく設定するstateからmutexWokwnを除外しています。

awokeという起きることと関連がありそうな名前と、waiterが0人の時はなにもしないということからUnlockに関係がありそうです。

なのでUnlockを見てみましょう。

mutex.go

func (m *Mutex) unlockSlow(new int32) {
	
	if new&mutexStarving == 0 {
		old := new
		for {
	
			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, 1)
				return
			}
			old = m.state
		}
	} else {
		runtime_Semrelease(&m.sema, true, 1)
	}

以前はスルーしていましたが、mutexWokenの条件がありますね。
old&(mutexLocked|mutexWoken|mutexStarving) != 0
new = (old - 1<<mutexWaiterShift) | mutexWokenとなっているので、forとなっていてもunlock一回につき一人のGを起こすだけとなります。

mutex.go

            runtime_SemacquireMutex(&m.sema, queueLifo, 1)
			starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
			old = m.state
			if old&mutexStarving != 0 {
				省略...
				break
			}
			awoke = true
			iter = 0

Unlockから起こされたときにもawokeが関わっています。
awoke=trueとなるのはspin中、もしくは目覚めたときということですね。awoke=trueになるGは複数生まれるのでしょうか？それ一つのGのみなのでしょうか。
結論から言えば一つのGのみなのですが、
UnlockとLockを合わせて、動きを見ていきましょう。

2パターン考えてみます。

先にLock側でmutexWokenフラグが立っているときからUnLockする場合
Unlock側で初めてmutexWokenフラグを立てる場合

まず１の場合

spin中awoke=trueとなるGが生まれて、stateにmutexWokenフラグが立つ
↓
Unlock側で old&(mutexLocked|mutexWoken|mutexStarving) != 0 の条件がtrueになりreturnするので、sema.goで目覚めさせる動きをしない
↓
awoke=trueとなったＧがLockSlow()でCASを取得するまではmutexWokenは解除されないので、unLockではsema.go経由での目覚ましはなし

2の場合

unlockでmutexWokenを付け、そのままsema.goで目覚めさせる流れに
↓
mutex.goにいるGがspin中に入っても、old&mutexWoken == 0に引っかかるのでどのGもawoke=falseのままで、
new &^= mutexWokenでmutexWokenがはがれない
↓
unlockから起こされたGが、awoke=trueとなり、そこからは１と一緒

ここから分かることはunlockより先にspinしているやつがあるときに、unlockからわざわざ起こさないようにするということで、
今mutex.goにあり、現在ロックを獲得しようとしているG > 眠りについて起こされるのを待っているGという構図になっていることです。
sema.goで眠っているGは、新しいGが入って来て先にmutexWokenフラグを立てられてしまえばもう目覚められないということです。

なぜこのような挙動をするか考えてみた結果、
もし古いＧから順に目覚めさせるとするとstarvingModeと同じ挙動になってしまい、Ｇのコンテキストスイッチが発生する分遅くなってしまうから。
なので、とりあえず今動いているＧは出来る限りコンテキストスイッチを発生させずロックを取得させてあげて、staringModeになってしまうくらい待たされた古いGについては非効率なstarvingModeで我慢
というのが僕の結論です。(詳しい方いたら訂正お願いします。)

以上でawokeについての解説、およびsync.mutex理解シリーズを終わりたいと思います。
最後のawokeの実装理由については推測となってしまいまい、終わり方としては良くなかったかもしれないですが訂正してくださったり、議論の種にでもなればと思います。

次回はselect(もしくはchannnelから？)でも見ていきたいです。
selectはsudoGの使われ方や、default,caseの選出の仕方(ランダム!)が面白いので解説していければなと思います。