douweng9427 2018-06-19 19:36
浏览 87


func (s *Server) start() {
         defer s.Unlock()
        if !s.isClosed{
           go s.processing()
        go s.start()

func (s *Server) processing() {
  // do stuff

I have a working Golang project that has a block of code following the logic shown above.

I don't understand why this logic works as I would've expected a deadlock.

  • 写回答

1条回答 默认 最新

  • douyun1546 2018-06-19 19:47

    We'll call the initial goroutine that's running when start is entered G1.

    1. start (in G1) locks the mutex and defers the unlock until start returns.
    2. start calls s.processing in a new goroutine (G2)
    3. start calls itself in a new goroutine (G3)
    4. start (G1) unlocks the mutex and returns.

    None of those calls except the lock at Step 1 is a blocking call. Concurrently, in G2, s.processing waits for start to unlock the mutex (which will happen pretty quickly because all start does is start a couple goroutines before unlocking the mutex). Also concurrently, in G3, the above 4 steps are performed all over again (on an apparently infinite loop).

    There is no point in that logic that could cause a deadlock.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?



  • ¥100 需求高精度PT100设计电路和算法
  • ¥15 单片机配网,继电器开关,广播
  • ¥60 Qcustomplot绘制实时动态曲线
  • ¥20 运用matlab画x-y图
  • ¥15 用idea运行项目,运行tomcat报错:断言失败
  • ¥15 Sqlserver查询链接服务器数据问题
  • ¥15 Bibtex4Word 引用中文文献
  • ¥20 用opencv c/c++ 转换成灰度图,然后做一下直方图均衡,输出mp4文件
  • ¥20 matlab中的双层数值积分
  • ¥50 服务器打印水晶报表问题