golang sync.mutex 超时select

Python015

golang sync.mutex 超时select,第1张

做了一个参考实例。假设某线程占用时间5秒,超时时间为2秒

func mian() {

lock := sync.Mutex{}

lock.Lock()

defer lock.Unlock()

timer := time.NewTimer(2 * time.Second)

end:=make(chan int)

go func() {

time.Sleep(5*time.Second)

fmt.Println("wait")

end<-1

}()

select {

case <-end:

case <-timer.C:

}

fmt.Println("End")

}

在 Golang 游戏leaf系列(一) 概述与示例 (下文简称系列一)中,提到过Go模块用于创建能够被 Leaf 管理的 goroutine。Go模块是对golang中go提供一些额外功能。Go提供回调功能,LinearContext提供顺序调用功能。善用 goroutine 能够充分利用多核资源,Leaf 提供的 Go 机制解决了原生 goroutine 存在的一些问题:

我们来看一个例子(可以在 LeafServer 的模块的 OnInit 方法中测试):

这里的 Go 方法接收 2 个函数作为参数,第一个函数会被放置在一个新创建的 goroutine 中执行,在其执行完成之后,第二个函数会在当前 goroutine 中被执行。由此,我们可以看到变量 res 同一时刻总是只被一个 goroutine 访问,这就避免了同步机制的使用。Go 的设计使得 CPU 得到充分利用,避免操作阻塞当前 goroutine,同时又无需为共享资源同步而忧心。

这里主动调用了 d.Cb(<-d.ChanCb) ,把这个回调取出来了。实际上,在skeleton.Run里会自己取这个通道

看一下源码:

New方法,会生成指定缓冲长度的ChanCb。然后调用Go方法就是先执行第一个func,然后把第二个放到Cb里。现在手动造一个例子:

这里解释一下,d.Go根据源码来看,实际也是调用了一个协程。然后上面两次d.Go并不能保证先后顺序。目前的输出结果是1+2那个先执行了,把3写入d.ChanCb,然后把3读出来,继续读时,d.ChanCb里没有东西,阻塞了。然后1+1那个协程启动了,最后又读到了2。

现在把time.Sleep(time.Second)的注释解开,会是啥结果呢

这里执行到time.Sleep睡着了,上面两个d.Go仍然是不确定顺序的,但是会各自的function先执行掉,然后陆续把cb写入d.ChanCb。看这次输出,1+2先写进去的。所以最后执行d.Cb时,就把3先读出来了。然后d.ChanCb的长度为1,说明还有一个,就是输出2了。

另外,就是close时会判断g.pendingGo

这个例子的意思很明显,NewLinearContext这种方式,即使先调用的慢了半秒,它还是会先执行完。

这里先是用了一个list,加入的时候用mutexLinearGo锁了,都加到最后。然后新开协程去处理,读的时候从最前面开始读,也要用mutexLinearGo锁。执行的时候,也要上锁mutexExecution,确保f()执行完并且写入g.ChanCb回调,这个mutexExecution锁才会解除。现在可以改造一个带回调的例子:

结果说明,确实是2先被写入了d.ChanCb。

如果该函数会修改receiver,此时一定要用指针

如果receiver是 struct 并且包含互斥类型 sync.Mutex ,或者是类似的同步变量,receiver必须是指针,这样可以避免对象拷贝

如果receiver是较大的 struct 或者 array ,使用指针则更加高效。多大才算大?假设struct内所有成员都要作为函数变量传进去,如果觉得这时数据太多,就是struct太大

如果receiver是 struct , array 或者 slice ,并且其中某个element指向了某个可变量,则这个时候receiver选指针会使代码的意图更加明显

如果receiver使较小的 struct 或者 array ,并且其变量都是些不变量、常量,例如 time.Time ,value receiver更加适合,因为value receiver可以减少需要回收的垃圾量。