• Go学习笔记 -- 控制协程执行顺序


           在 Go 里面的协程执行实际上默认是没有严格的先后顺序的。由于 Go 语言 GPM 模型的设计理念,真正执行实际工作的实际上是 GPM 中的 M(machine) 执行器,而我们的协程任务 G(goroutine) 协程需要被 P(produce) 关联到某个 M 上才能被执行。而每一个 P 都有一个私有队列,除此之外所有的 P 还共用一个公共队列。因此当我们创建了一个协程之后,并不是立即执行,而是进入队列等待被分配,且不同队列之间没有顺序关系可言。

           但是在有些时候,我们并不是希望所有的协程都随机执行,所以我们需要想办法控制协程的执行顺序,这里整理了几种控制协程执行顺序的方法。

    循环控制

    思路就是我们要给每一个子协程设置一个序号,当前一个序号的协程执行完之后,才能执行下一个。
    所以我们需要一个公共变量去记录当前可以执行的协程的序号,同时这个变量必须是线程安全的,以确保对于每个协程的每一次读写操作都是正确的。
    首先循环等待合适的时机:
    这个函数会不断循环获取一个 count 值,当 count 的值和参中的 i 相同时,他就会进入执行参数 fn 代表的函数,并且将 count 的值 +1
    否则它将等待一纳秒然后重复以上步骤。

    var count uint32
    
    func sequence(i uint32, fn func()) {
    	for {
    		//使用原子操作
    		if n := atomic.LoadUint32(&count); n == i {
    			fn()
    			atomic.AddUint32(&count, 1)
    			break
    		}
    		time.Sleep(time.Nanosecond)
    	}
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13

    然后用 sequence 来控制协程顺序:
    我们将要执行的逻辑放在函数 fn 中,并放在 sequence 函数中执行,由函数 sequence 去确保写成的执行顺序。
    最后 sequence(times, func() {}) 是为了让主协程最后退出,当然我们可一个使用通道 chan 去实现(可以参考上一篇)。

    func main() {
    	var times uint32 = 5
    	for i := uint32(0); i < times; i++ {
    		go func(i uint32) {
    			fn := func() {
    				fmt.Printf("this i is %v\n", i)
    			}
    			sequence(i, fn)
    		}(i)
    	}
    	//让主协程等待最后执行
    	sequence(times, func() {})
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13

    执行结果:

    this i is 0
    this i is 1
    this i is 2
    this i is 3
    this i is 4
    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    通道控制

    原理就是,前后协程之间通过通道去相互限制,后一个协程尝试去获取一个通道里面的值,当通道中没有值时,就会一直阻塞。
    而前一个协程则负责关闭通道,或向通道中发送值,当前一个协程完成了这个操作,后一个协程才可以结束阻塞,继续执行。

    func main() {
    	c1 := make(chan struct{})
    	c2 := make(chan struct{})
    	c3 := make(chan struct{})
    
    	go func() {
    		//协程一 不受限制 直接执行 执行结束后关闭通道一
    		fmt.Println("this value is 0")
    		close(c1)
    	}()
    	go func() {
    		//协程二 需要从通道一中接收值 ,或者通道关闭时,获取到接收失败的结果,否则一直阻塞
    		//执行结束后关闭通道二
    		<-c1
    		fmt.Println("this value is 1")
    		close(c2)
    	}()
    	go func() {
    		//协程三 需要从通道二中接收值 ,或者通道关闭时,获取到接收失败的结果,否则一直阻塞
    		//执行结束后关闭通道三
    		<-c2
    		fmt.Println("this value is 2")
    		close(c3)
    	}()
    	
    	//主协程 需要从通道三中接收值 ,或者通道关闭时,获取到接收失败的结果,否则一直阻塞
    	<-c3
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28

    执行结果

    this value is 0
    this value is 1
    this value is 2
    
    • 1
    • 2
    • 3

    互斥锁 async.Mutex

    直接上代码

    func main() {
    	times := 5
    	//创建一个互斥锁数组 多一个给主协程用
    	var cc = make([]*sync.Mutex, times+1)
    	//往数组中塞入互斥锁,默认直接加锁
    	for i := 0; i < len(cc); i++ {
    		m := &sync.Mutex{}
    		m.Lock()
    		cc[i] = m
    	}
    	for i := 0; i < times; i++ {
    		//创建子协程
    		go func(index int) {
    			//子协程尝试为数组中对应 index 位置的锁加锁,获取不到锁就等待
    			//因为初始化的这些互斥锁默认就已经被锁住了,所以这里创建的子协程都会被阻塞
    			//一旦获取到锁,就执行逻辑,最后将当前index的锁和index+1的锁释放,这样正在等待 index +1 位置的锁的子协程就可以继续执行了
    			cc[index].Lock()
    			fmt.Printf("this value is %d \n", index)
    			cc[index].Unlock()
    			cc[index+1].Unlock()
    		}(i)
    	}
    	//将index 为 0 位置的锁解锁,让第一个子协程可以继续执行
    	cc[0].Unlock()
    	//为 index 为 times 的锁加锁,只有当最后一个子协程执行完毕后,这个锁才会解锁,主协程才能继续向下走
    	cc[times].Lock()
    	cc[times].Unlock()
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
  • 相关阅读:
    C语言日记 37 类的友元(1)(全局函数做友元)
    java-net-php-python-java机场航班调度管理系统计算机毕业设计程序
    RSA加密和解密原理及过程(非对称加密)
    C++_pen_类
    Zabbix 5.0 监控教程(四)
    Kibana-8.4.0-Linux安装
    【docker desktop】MongoDB配置并用NodeJS连接
    告别繁琐流程,让你轻松成为电子画册制作达人!
    题目:2706.购买两块巧克力
    Nginx转发丢失cookie表现形式以及解决方案
  • 原文地址:https://blog.csdn.net/qq_40096897/article/details/127828781