关于多线程安全的队列……

乐天

在linux下给每个客户端分配一个线程……
你不是来玩我们的吧？

tarkey

对啊，为什么要给每个用户一个线程呢？

linur

sjinny: Re: 关于多线程安全的队列……

谢谢你们~ [em13]

CriticalSection我查过了，只能在win上用，唯一不理解的是它似乎和互斥量是类似的但是...

是的，在WIN32上，mutex是内核对象，而CriticalSection则不是，因此，用
CriticalSection不会切换到内核状态，用它速度要快些

sjinny

谢谢linur~

乐天，tarkey，我的想法是这样的：
服务器和客户端的连接都是TCP连接，给每个客户端一个线程，让这个客户端的线程去阻塞地读取TCP socket，每读取一个完整的数据包，就把这个数据包解压、解密(如果需要的话)，然后将得到的操作请求放进一个队列，这样就能保证按数据包到达服务器的先后顺序来处理操作请求，这样一定程度上能保证游戏的公平。
我也想过，想用一个线程来读取所有的socket(使用select()……)，但是发现这样的话，很难按时间顺序来处理操作请求(因为是顺序遍历一个八叉树……)。
其实我觉得，一台服务器不可能同时给太多人提供服务，Linux下一个进程能创建上千个线程，我想一台服务器能支持千人同时在线就很不容易了……更何况我想做的是3D网游，带有一定的FPS游戏的特点，服务器负担本来就会比较重……

tarkey

为什么不考虑这种模式？

while(1)
{
     检查哪个socket可以读或者写;
     如果没有端口可以读写 continue;
     否则，循环的处理读入的数据
   循环的处理该写出去的数据
}
这样比阻塞的读方便多了，因为实际上阻塞的时候，一样要消耗CPU资源。
开启的线程越多，CPU就会开销更多的时间在在线程间切换和IO切换去检查是否
可以读写上。一般对于服务器来说，唯一的负担就是IO负担，各种的IO。
IO的负担并不是在可以支持多少个连接上，而是在于连接发送消息的大小和频率
上，频率越大，服务器IO切换的负担越大。如果你不信，你自己写个客户端不停
的给服务器发消息，然后在服务器trace一下系统调用会发现吃掉CPU资源的系统
调用是select，不管你用IOCP还是自己写，最终的系统调用就是select。

sjinny

tarkey，谢谢~
我以前也考虑过这种模式(好象就是因为队列的问题……)，但是似乎有个问题：
某个socket可读，于是对其进行处理，在这个处理过程中如果有多个socket变为可读，那么这次处理完后进入下一次循环后，会发现有多个socket是可读的，但是却不知道这些socket状态变化的先后顺序……
不过现在发现多线程的模式也有同样的问题：
因为同一时刻只有一个线程能write队列，其他想write的线程则被挂起，如果某个线程A在write队列的过程中，有多个线程先后想write队列而被挂起，那么线程A完成写入后，那些被挂起的线程被激活的顺序不一定与它们socket数据到达的顺序一致……

这样我又不知道该用什么样的设计了…………………………  

tarkey

。。。。这个不是大问题。
你处理的时候单开线程处理没问题，但是IO一定不能阻塞住。
你可以select的时候发现可以读的，然后开个线程去处理，然后马上返回。
继续select。。。

sjinny

tarkey: Re:关于多线程安全的队列……

。。。。这个不是大问题。
你处理的时候单开线程处理没问题，但是IO一定不能阻塞住。
你可以select的时候发现可以读的，然后开个线程去处理，然后马上返回。
继续select。。。

但是那样的话，不就和多线程的办法一样了吗？还是有队列的问题呀~ [em6]

tarkey

我的意思不是多线程，而仅仅只是两个线程，一个监视IO，一个负责处理。
先来先处理，这样有什么不妥当吗？
while(1)
{
    if(check_io() == READABLE) queue.insert(read_io());
    ....
}

while(1)
{
    if(!queue.empty())
        process(queue.get());
}

sjinny

4242~问题不是这个，问题在于，负责IO的那个线程要把数据包转交给那另一个线程来处理，但是那么多连接，怎么保证所有数据包按照到达的顺序被处理呢？ [em7]