Why the mutex code stops another whole go-routine?

var m *sync.RWMutex
func main() {
	m = new(sync.RWMutex)
	n := 100
	go func() {
		for i := 0; i < n; i++ {
			write("WA", i)
		}
	}()

	go func() {
		for i := 0; i < n; i++ {
			write("WB", i)
		}
	}()

	select {}
}
func write(tag string, i int) {
	m.Lock()
	fmt.Printf("[%s][%s%d]write start \n", tag, tag, i)
	time.Sleep(100 * time.Millisecond)
	fmt.Printf("[%s][%s%d]write end \n", tag, tag, i)
	m.Unlock()

	// time.Sleep(1 * time.Millisecond)
}

Result in console:

> go run mutex.go
[WB][WB0]write start
[WB][WB0]write end
[WB][WB1]write start
[WB][WB1]write end
[WB][WB2]write start
[WB][WB2]write end
[WB][WB3]write start
[WB][WB3]write end
[WB][WB4]write start
[WB][WB4]write end
[WB][WB5]write start
[WB][WB5]write end
[WB][WB6]write start
[WB][WB6]write end
[WB][WB7]write start
[WB][WB7]write end
[WB][WB8]write start
[WB][WB8]write end
[WB][WB9]write start
[WB][WB9]write end
...

> go version
go version go1.5.2 windows/amd64

The question is:
why there is no chance for the go-routine of "[WA]"?
Why the mutex code stops another whole go-routine?

I know there must be a story or a theory about it.
Please give me a url to read and study.

This situation is called live lock.

When you call m.Unlock() even though two goroutines (A and B) are waiting for this lock to be released the scheduler is free to wake up any of them to proceed.

It looks like the current implementation of scheduler in Go doesn't switch to goroutine A fast to enough for it to acquire the mutex. Before this happens goroutine B re-acquires the mutex.

As you probably found out if you move time.Sleep call after m.Unlock call both A and B goroutines will be running concurrently.

Hopefully this makes sense.

Go uses cooperative multitasking; it doesn't use preemptive mutitasking: Computer multitasking. You need to give the scheduler an opportunity to run between locks. For example, by a call to Gosched(),

package main

import (
	"fmt"
	"runtime"
	"sync"
	"time"
)

var m *sync.RWMutex

func main() {
	m = new(sync.RWMutex)
	n := 100
	go func() {
		for i := 0; i < n; i++ {
			write("WA", i)
		}
	}()

	go func() {
		for i := 0; i < n; i++ {
			write("WB", i)
		}
	}()

	select {}
}

func write(tag string, i int) {
	m.Lock()
	fmt.Printf("[%s][%s%d]write start \n", tag, tag, i)
	time.Sleep(100 * time.Millisecond)
	fmt.Printf("[%s][%s%d]write end \n", tag, tag, i)
	m.Unlock()
	runtime.Gosched()
}

Output:

[WB][WB0]write start 
[WB][WB0]write end 
[WA][WA0]write start 
[WA][WA0]write end 
[WB][WB1]write start 
[WB][WB1]write end 
[WA][WA1]write start 
[WA][WA1]write end 
[WB][WB2]write start 
[WB][WB2]write end 
[WA][WA2]write start 
[WA][WA2]write end 
[WB][WB3]write start 
[WB][WB3]write end 
[WA][WA3]write start 
[WA][WA3]write end 

@peterSO 's answer is correct. Just to elaborate a bit on scheduling, that for loop is a sequential tight loop. Means that the compiled instructions from that loop, would occupy a whole thread to finish. Meanwhile other bits of low level instructions would block unless they have some schedule cycles provided by runtime.Gosched() or sleep, in the middle of the loop. That's why they actually have not a chance to catch on with the sync.Mutex (BTW both should be sync.Mutex at declaration and instantiation):

go func() {
	for i := 0; i < n; i++ {
		runtime.Gosched()
		write("WA", i)
	}
}()

go func() {
	for i := 0; i < n; i++ {
		runtime.Gosched()
		write("WB", i)
	}
}()

And Go scheduler is not preemptive at instruction level (like Erlang). That's why it's better to orchestrate execution path using channels.

Note: I've learnt this the hard way (not a low-level Go compiler expert). And channels provide that orchestration on Go-Routines (& those extra cycles) in a more clean manner. In other words sync.Mutex should be used just for supervising access to stuff; not for orchestration.