tcp读取数据的时候,断开后一段时间后出现死锁 about libgo HOT 17 OPEN

@gooker @qinrhx

我这两天仔细看了一下这个代码，发现这个锁加的不太好,巨大的区域锁(有空了代码仔细看明白了，我重构重构这个锁)。上面那个tcp模块的死锁我找到原因了
复现方法:写了个httpserver epoll方式。开50个client并发，一直发发get请求，不出30秒就死锁了。

测试出了两处死锁

死锁1:

线程1
routine_sync/timer.h run函数 timer.h 150行 bool locked = invoke_lock.try_lock();
scheduler/processer.cpp WakeupBySelf函数 processer:cpp 381行 std::unique_lockTaskQueue::lock_t lock(waitQueue_.LockRef());

线程2
scheduler/processer.cpp WakeupBySelf函数 processer:cpp 381行 std::unique_lockTaskQueue::lock_t lock(waitQueue_.LockRef());
routine_sync/timer.h run函数 timer.h 128行 std::unique_lock invoke_lock(*invoke_mtx);

我仔细看了一下代码waitQueue_.LockRef()这个锁不好改，这个锁不仅锁携程调度队列，还要task，改了会导致压入的数据校验的时候，多线程会置空。我得做法是屏蔽掉 routine_sync/timer.h run函数 timer.h 128行 std::unique_lock invoke_lock(*invoke_mtx); 写了个http并发示例测试了半个小时暂时没发现有异常。代码没细细研究，暂时不清楚拆了这块会导致什么异常问题。暂时看没发现有崩溃情况。

死锁2：
打开debug模式 DebugPrint宏里有个锁和TSQueue里的队列锁会形成死锁。

我得处理办法是 TSQueue size计数换成原子计数

from libgo.

from libgo.

连接的时候使用如下的非阻塞方式,不确定对libgo 有没有影响

//非阻塞方式连接
        int error=-1, len;
        len = sizeof(int);
        struct timeval tm;
        fd_set set;
        unsigned long ul = 1;
        ioctl(sockfd, FIONBIO, &ul); //设置为非阻塞模式
        if( connect(sockfd,(struct sockaddr *)&plcaddr,sizeof(plcaddr)) == -1)
        {
            tm={out_time,0};//10s
            //tm.tv_set = TIME_OUT_TIME;
            //tm.tv_uset = 0;
            FD_ZERO(&set);
            FD_SET(sockfd, &set);
            if(select(sockfd+1, NULL, &set, NULL, &tm) > 0)
            {
                getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, (socklen_t *)&len);
                if(error == 0)
                    ret = true;
                else
                    ret = false;
            }
            else
                ret = false;
        }
        else
            ret = true;
        
        ul = 0;
        ioctl(sockfd, FIONBIO, &ul); //设置为阻塞模式

from libgo.

这库还维护不？我也遇到了死锁，服务跑几天就会出现，__lll_lock_wait只有一个线程出来，然后好几个线程在LFLock上面，把cpu都跑满了，提交的协程也不再执行，截几个图出来看有没帮助

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

from libgo.

@qinrhx 多谢,等有时间我试试,不好复现

from libgo.

我也遇到了这个问题，难受的一逼莫名奇妙死锁了。你用的是哪个版本

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

你换的哪个版本啊

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

@gooker 你用的哪个版本啊，跪求

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

@gooker 你用的哪个版本啊，跪求

我用的最新的,暂时没测试没换版本

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

@gooker 你用的哪个版本啊，跪求

我用的最新的,暂时没测试没换版本

@gooker matser分支不是还存在死锁问题嘛，我换3.1-stable发现这个版本有bug，携程有时候会空转

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

你换的哪个版本啊

@SignalEmit 具体哪个版本不记得了，是之前从master下载的，你找master提交记录更换锁套件之前的试试吧，比如这个

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

你换的哪个版本啊

@SignalEmit 具体哪个版本不记得了，是之前从master下载的，你找master提交记录更换锁套件之前的试试吧，比如这个
@qinrhx 我切过这个版本，这个版本有bug。举个例子
go{
while(true){
sleep(1);
}
};
这个休眠挂起这里会出bug，无限空转，sleep也失效了。还会影响其他携程。3.1的稳定版也有这问题

from libgo.

@qinrhx 这个协程调用函数有锁,协程外也对这个锁也有处理,容易锁. 我这里只是用了tcp非阻塞遇到问题,改成阻塞貌似还正常.

我看更新记录，近期有更换了协程锁套件。应该是这个锁套件有bug，我换回原来的版本，跑了一个星期没出现死锁。 @gooker

你换的哪个版本啊

@SignalEmit 具体哪个版本不记得了，是之前从master下载的，你找master提交记录更换锁套件之前的试试吧，比如这个
@qinrhx 我切过这个版本，这个版本有bug。举个例子
go{
while(true){
sleep(1);
}
};
这个休眠挂起这里会出bug，无限空转，sleep也失效了。还会影响其他携程。3.1的稳定版也有这问题

哦，这我倒没测过，我没有在协程里做循环休眠的。
之前是听说定时器有内存泄漏，失效的bug，你看看能不能改下业务逻辑避免掉了。
这个库看上去bug不少，也不怎么维护了，所以能不用就别用了。。。要用也简单用

from libgo.

@gooker @qinrhx

我这两天仔细看了一下这个代码，发现这个锁加的不太好,巨大的区域锁(有空了代码仔细看明白了，我重构重构这个锁)。上面那个tcp模块的死锁我找到原因了
复现方法:写了个httpserver epoll方式。开50个client并发，一直发发get请求，不出30秒就死锁了。

测试出了两处死锁

死锁1:

线程1
routine_sync/timer.h run函数 timer.h 150行 bool locked = invoke_lock.try_lock();
scheduler/processer.cpp WakeupBySelf函数 processer:cpp 381行 std::unique_lockTaskQueue::lock_t lock(waitQueue_.LockRef());

线程2
scheduler/processer.cpp WakeupBySelf函数 processer:cpp 381行 std::unique_lockTaskQueue::lock_t lock(waitQueue_.LockRef());
routine_sync/timer.h run函数 timer.h 128行 std::unique_lock invoke_lock(*invoke_mtx);

我仔细看了一下代码waitQueue_.LockRef()这个锁不好改，这个锁不仅锁携程调度队列，还要task，改了会导致压入的数据校验的时候，多线程会置空。我得做法是屏蔽掉 routine_sync/timer.h run函数 timer.h 128行 std::unique_lock invoke_lock(*invoke_mtx); 写了个http并发示例测试了半个小时暂时没发现有异常。代码没细细研究，暂时不清楚拆了这块会导致什么异常问题。暂时看没发现有崩溃情况。

死锁2：
打开debug模式 DebugPrint宏里有个锁和TSQueue里的队列锁会形成死锁。

我得处理办法是 TSQueue size计数换成原子计数

from libgo.

现在这个库不怎么维护了是大问题，都不敢用了

from libgo.