Mutex和上厕所居然有这么多异曲同工之妙

kevin_tech

于 2021-07-19 08:35:44 发布

阅读量88

点赞数 1

文章标签： sms 多进程分布式存储 nokia c++11

本文采取对话形式，有两个登场人物，左边是导师：欧阳狂霸，右边是实习生：三多。

提示：浅色主题阅读体验更佳。

Mutex介绍

欧阳狂霸小课堂

<<< 左右滑动见更多 >>>

func concurIncr() {
 var wg sync.WaitGroup

 wg.Add(10)

 var a int
 for i := 0; i < 10; i++ {
  go func() {
   defer wg.Done()
   for j := 0; j < 1000; j++ {
    a++
   }
  }()
 }
 wg.Wait()

 println(a) // 小于10000的随机数。
}

欧阳狂霸小课堂

<<< 左右滑动见更多 >>>

CAS用来保证加锁过程中的原子性，会比较地址指针是否为old，

为old说明操作期间没有被打断，

就地址值替换为new，返回true,

不为old, 代表操作期间被其他线程打断了，返回false。

CAS伪代码：

 bool Cas(int32 *val, int32 old, int32 new)
 Atomically:
 if(*val == old){
  *val = new;
  return 1;
 }else
  return 0;

CAS汇编码：

TEXT runtime∕internal∕atomic·Cas(SB), NOSPLIT, $0-13
	MOVL	ptr+0(FP), BX
	MOVL	old+4(FP), AX
	MOVL	new+8(FP), CX
	LOCK
	CMPXCHGL	CX, 0(BX)
	SETEQ	ret+12(FP)
	RET


func main() {
 a := 1

 var mu sync.Mutex

 go func() {
  mu.Lock()
  println("lock")
  a += 2
  //time.Sleep(time.Second)
  time.Sleep(time.Second)
  println("unlock")
  mu.Unlock()
 }()

 go func() {
  println("other")
  a += 3
  println("done")
 }()

 time.Sleep(time.Second * 5)
}
//print :
//   lock
//   other
//   done
//   unlock

Mutex使用

等待的goroutine执行的顺序是什么
非cpu中的goroutine的切换是有性能损耗的，正处于cpu切换的goroutine的切换不需要做上下文切换，如何设计以获得更好的性能
如果某个goroutine一直得不到调度怎么办
有的协程临界资源可能很快，但如果恰好其他线程抢锁没抢到，那它就要去排队吗？有没有啥方法让这个协程多抢一会

欧阳狂霸小课堂

<<< 左右滑动见更多 >>>


func main() {
 a := 1

 var mu sync.Mutex

 go func() {
  mu.Lock()
  println("lock")
  a += 2
  //time.Sleep(time.Second)
  time.Sleep(time.Second)
 }()

 go func() {
  a += 3
  println("unlock")
  println(a)
  mu.Unlock()
 }()

 time.Sleep(time.Second * 5)
}

func concurIncr() {
 var wg sync.WaitGroup
 var mu sync.Mutex

 wg.Add(10)

 var a int
 for i := 0; i < 10; i++ {
  go func() {
   defer wg.Done()
   for j := 0; j < 1000; j++ {
    mu.Lock()
    a++
    mu.Unlock()
   }
  }()
 }
 wg.Wait()

 println(a) // 10000
}

type SafeCounter struct {
 mu sync.Mutex
 v  map[string]int
}

func (c *SafeCounter) Inc(key string) {
 c.mu.Lock()
 // Lock so only one goroutine at a time can access the map c.v.
 c.v[key]++
 c.mu.Unlock()
}

func (c *SafeCounter) Value(key string) int {
 c.mu.Lock()
 // Lock so only one goroutine at a time can access the map c.v.
 defer c.mu.Unlock()
 return c.v[key]
}

func foo() {
  mu.Lock()
  defer mu.Unlock() 


  // 如果不用defer 
  err := ...
  if err != nil{
      //log error
      return  //需要在这里Unlock()
  }
  
  return //需要在这里Unlock()
}

func (t *Transport) CloseIdleConnections() {
 t.nextProtoOnce.Do(t.onceSetNextProtoDefaults)
 t.idleMu.Lock()
 m := t.idleConn
 t.idleConn = nil
 t.closeIdle = true // close newly idle connections
 t.idleLRU = connLRU{}
 t.idleMu.Unlock()
 for _, conns := range m {
  for _, pconn := range conns {
   pconn.close(errCloseIdleConns)
  }
 }
 if t2 := t.h2transport; t2 != nil {
  t2.CloseIdleConnections()
 }
}

Mutex易错点

Panic


func  misuse() {
 var mu sync.Mutex

 mu.Unlock() // fatal error: sync: unlock of unlocked mutex
}

死锁

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

type DataStore struct {
 sync.Mutex // ← this mutex protects the cache below
 cache map[string]string
}

func (ds *DataStore) get(key string) string {
 ds.Lock()
 defer ds.Unlock()
 
 if ds.count() > 0 { <-- count() also takes a lock!
  item := ds.cache[key]
  return item
 }
 return ""
}

func (ds *DataStore) count() int {
 ds.Lock()
 defer ds.Unlock()
 return len(ds.cache)
}

锁的粒度

// Don't do the following if you can avoid it
func doSomething() {
    mu.Lock()
    item := cache["myKey"]
    http.Get() // Some expensive io call
    mu.Unlock()
}

// Instead do the following where possible
func doSomething(){
    mu.Lock()
    item := cache["myKey"]
    mu.Unlock()
    http.Get() // This can take awhile and it's okay!
}