服务器堵塞了

Question

mutex同步用的不恰当1.虽然AcceptThread比RecevieThread先创建，
但有可能会RecevieThread函数比AcceptThread先执行，
结果就是RecevieThread占用mutex，但阻塞在recv处，
AcceptThread也被锁住了2.AcceptThread里boost::mutex::scoped_lock lock(g_mu);
最好要放在g_sockList.push_back(s);前面，即
if(s!= INVALID_SOCKET)
        {    
            boost::mutex::scoped_lock lock(g_mu);
            g_sockList.push_back(s);
        }
某些情况，如accept了一个连接，马上又执行到了lock(g_mu)（虽然有sleep(500)）,
此时又没连接上来，就一直塞住。3.前面的都是白说了，如果要accept多客户端，这里的代码根本就不行，
想一个线程就搞定多个客户端？还是阻塞模型的？不行
如果不熟悉select,iocp，那么先用一个客户端一个线程的模型。

Answer 1

1.虽然AcceptThread比RecevieThread先创建，
但有可能会RecevieThread函数比AcceptThread先执行，
结果就是RecevieThread占用mutex，但阻塞在recv处，
AcceptThread也被锁住了
RecevieThread 里是非堵塞，你看看 ioctsocketAcceptThread里的锁位置确实不对， 如 已经和一个客户端连接上了。所以就释放锁，然后 接受数据的线程获得所，接受数据，释放锁。此时AcceptThread又获得所，突然accept堵塞了，那么 接受数据 的线程非堵死不可（可能客户端第二次发送数据来，就接受不了， 接受数据的线程进不去。 ）3.acceptThread用堵塞，是没法子啊，非堵塞的返回值无法判断，而且立即进入了push_back，这个是不合理的。所以用堵塞。