收发线程池和分析线程池之间如何很好的配合工作？

lyzcom 2004-02-07 05:42:47

由于收发线程只负责收发，所以其收来的数据是放在一个全局的std::deque队例中（先入后出方式），即一旦有新的包，就首先要进入一个全局的临界区，然后push_back，接着激发一个全局的事件。这时，有好几个分析线程在该事件上等待。一旦事件被激发，所有的分析线程就都会活动，并从全局的这个std::deque队列中取数据。

现在我个人认为这样的结构是不怎么好的。因为牵涉到deque不断的push_back和pop_front操作，同时，如果分析处理线程处理速度很快，那么同一时间用不着所有的分析线程全部都被激活。真的毫无必要。但是，如果要想同一时间只激活一个线程，这样的算法和条件判断处理等，可能浪费的时间比激活所有线程还要多。真的不知道该怎么办了。

高手能不能给点方法，收发线程池和分析线程池之间如何配合最好？有没有更好的算法？

...全文

81 2 打赏收藏转发到动态举报

写回复

2 条回复

切换为时间正序

请发表友善的回复…

发表回复

MFCClass 2004-06-25

打赏
举报

回复

我学习

lostgdi731 2004-06-25

打赏
举报

回复

你根本没看我写的东西或还不理解。
你的问题不外乎这个。

说明一、受限制库Dll和lib说明：库文件G-TcpServer.lib、G-TcpServer.Dll是受限制的试用版本和Demo配套。 1、最大连接不能超过50 2、发送字节数不能超过50 3、不能设置0读投递、无超时机制 4、其他功能限制二、版本解读说明 1、版本名带T的表示是受限制的试用版 2、版本名带bata表示非正式版 3、版本名带WChar表示支持WideChar 4、版本号以时间格式累加计数（60进1）和显示三、文件“G-TcpServer无限制体验版.exe”是无限制的体验版。四、文件夹 1、Demos文件夹是VC Lib、Dll库及Delphi2010的例程源码，供开发学习 2、G-Sockets文件夹是Lib和Dll库的Delphi和VC的头文件 3、Release\G-Sockets\Dll文件夹是动态库的输出文件夹 4、Release\G-Sockets\Lib文件夹是静态库的输出文件夹 1、模块包含处理线程、工作线程和看守线程。工作线程负责IO投递工作，并响应投递返回，再把接收的数据投递给处理线程，处理线程调用回调函数给应用层，以此可以在通讯层和应用层之间现实0拷贝数据的功能。模块只有一个看守线程，负责：a、响应Accept事件并投递接受队列；b、效验接受超时（即只连接不发数据）断开连接，防止空连接；c、效验空闲超时（即心跳超时）断开连接。按工作量来分，最繁重的是处理线程，其次是工作线程，最闲的是看守线程。可通过OnThread事件回调函数设置线程权限。在此线程模式下，应用层可以在回调函数里处理数据而不必再建立另外的数据处理线程池。 2、线程平衡为使连接能平衡使用处理线程，每个连接同时只有一个处理线程处理工作线程投递过来的IO返回事件并调用回调函数通知应用层。 3、收发平衡为使连接能平衡使用IO设备，每个连接同时只能投递一个读请求，并通过线程平衡机制保证接收的数据是按顺序的被处理线程处理及通过回调函数传递给应用层；同时也只能投递一个写请求，其余写请求都按顺序放在写队列里面。读写同步都使用临界段。 4、0拷贝技术接收数据0拷贝看1项；提供GTcpSvr_AllocGBuf()、GTcpSvr_FreeGBuf()和GTcpSvr_PostSendGBuf()三个函数实现发送数据的0拷贝。 5、0读投递为避免内核锁定分页内存过多，可通过设置来采用0读投递来降低吞吐性能从而实现大连接量。 6、HndData回收 HndData回收有多种方法，但额外会在收发数据这两个频率操作上增加工作量，因此尽量避免在这两个操作时做太多的工作是有必要的。模块均不采用“投递计数”或“投递链表”的方式来判断回收HndData的时机，而是一旦断线立即回收，其他未决投递继续返回时只处理IoData，不对HndData做任何写操作。同时为避免HndData刚收回来但其未决投递还没有完全返回之前就立即被利用的可能性，HndData池采用了FIFO双锁并发链表，该链表通过ExNumber值来实现在最大连接情况下HndData池还有ExNumber个数量使链表不为NULL，通过设置ExNumber数量可实现控制链表末端的HndData出列时间，在这个时间内可以保证断开刚回收的HndData的未决投递能够完全返回。 HndData池，初始时如下： HD1 + HD2 + HD... + HDMaxConnection + HDEx1 + HDEx2 + HDEx... + HDExNumber | | Head------------------------------------------------------------------Tail 达到最大连接时如下: HDEx1 + HDEx2 + HDEx... + HDExNumber | | Head---------------------------Tail 断开回收一个HndData(HD)后如下： HDEx1 + HDEx2 + HDEx... + HDExNumber + HD | | Head-------(需要T时间HD才能出列)------Tail 注：T可以通过控制ExNumber值来实现，假定每秒最大可以处理C个连接和断开，需要延时T秒所有未决投递才会完全回收，那么：ExNumber = T * (MaxConnection / C)。实际上每个连接未决投递非常少（因为读写是单投递的），并且工作线程并不处理数据工作量不大，因此T很短，模块默认是3秒。对于服务器而已，一秒能接受的连接量是可知预计的，模块默认是1万，假定MaxConnection=C所以ExNumber是3万。但实际应用中，正常情况下连接率远少于1万/S，尤其是长连接的服务器，即使是短连接的服务器也不会发生这样的连接率。可能的情况是DOS，如果是影响也不大，因为还有MaxConnection控制，超过这个数的连接就立即被CloseSocket了。和频率高的数据收发相比，断线、连接的频率远少于它，在频率低的地方上多做多点工作总比在频率高的地方多做一点工作的好。 7、可伸缩性 IoData数量可根据初始需要设置，资源不足时模块自动向系统申请内存。为保证HndData的安全性，HndData池还设置了延时出列，刚回收的HndData入列时间必须超过3（或更长）秒钟，如果未达到3秒的，模块自动向系统申请内存。 8、内存管理 IoData和HndData均采用VirtualAlloc和VirtualFree来向系统操作内存。IoData池采用原子函数InterlockedCompareExchange来操作进出栈。HndData采用单向FIFO双锁并发链表来管理出入列操作。其他小内存需求的均采用静态数组或new操作。五、内存需求每个IoData等于一个分页内存大小，信息头大小为36Byte，有效使用内存是4060Byte，因此对GTcpSvr_AllocGBuf获得的内存写入时不应该超过4060（调用GTcpSvr_GetGbufSize获得），所有IoData占用系统内存是：IoDataCount * PageSize（4096）。每个HndData大小是128Byte，加上每个Socket分配时耗内存约是：540Bytes（此为估计值，应以MS技术文档为准），所有HndData耗系统内存是：HndDataCount * MAX_HNDDATA_AND_SOCKET_SIZE（128 + 540）。其他变量和数组可能耗得内存在10M之下。综上，整个模块需求内存量是：UseMemSize = IoDataCount * PageSize + HndDataCount * MAX_HNDDATA_AND_SOCKET_SIZE + 10M。

本资源设置1个资源分，您可以下载作为捐献。如果您有Git，还可以从http://www.goldenhawking.org:3000/goldenhawking/zoom.pipeline直接签出最新版本 (上一个版本“一种可伸缩的全异步C/S架构服务器实现”是有问题的，现在已经完成更改)。服务由以下几个模块组成. 1、网络传输模块。负责管理用于监听、传输的套接字，并控制数据流在不同线程中流动。数据收发由一定规模的线程池负责，实现方法完全得益于Qt的线程事件循环。被绑定到某个Qthread上的Qobject对象，其信号-槽事件循环由该线程负责。这样，便可方便的指定某个套接字对象使用的线程。同样，受惠于Qt的良好封装，直接支持Tcp套接字及SSL套接字，且在运行时可动态调整。（注：编译这个模块需要Qt的SSL支持，即在 configure 时加入 -openssl 选项） 2、任务流水线模块。负责数据的处理。在计算密集型的应用中，数据处理负荷较重，需要和网络传输划分开。基于普通线程池的处理模式，也存在队列阻塞的问题——若干个客户端请求的耗时操作，阻塞了其他客户端的响应，哪怕其他客户端的请求很短时间就能处理完毕，也必须排队等待。采用流水线线程池避免了这个问题。每个客户端把需要做的操作进行粒度化，在一个环形的队列中，线程池对单个客户端，每次仅处理一个粒度单位的任务。单个粒度单位完成后，该客户端的剩余任务便被重新插入到队列尾部。这个机制保证了客户端的整体延迟较小。 3、服务集群管理模块。该模块使用了网络传输模块、任务流水线模块的功能，实现了跨进程的服务器ßà服务器链路。在高速局域网中，连接是快速、稳定的。因此，该模块被设计成一种星型无中心网络。任意新增服务器节点选择现有服务器集群中的任意一个节点，接入后，通过广播自动与其他服务器节点建立点对点连接。本模块只是提供一个服务器到服务器的通信隧道，不负责具体通信内容的解译。对传输内容的控制，由具体应用决定。 4、数据库管理模块。该模块基于Qt的插件式数据库封装QtSql。数据库被作为资源管理，支持在多线程的条件下，使用数据库资源。 5、框架界面。尽管常见的服务运行时表现为一个后台进程，但为了更好的演示服务器的功能，避免繁琐的配置，还是需要一个图形界面来显示状态、设置参数。本范例中，界面负责轮训服务器的各个状态，并设置参数。设置好的参数被存储在一个ini文件中，并在服务开启时加载。 6、应用专有部分模块。上述1-4共四个主要模块均是通用的。他们互相之间没有形成联系，仅仅是作为一种资源存在于程序的运行时（Runtime）之中。应用专有部分模块根据具体任务需求，灵活的使用上述资源，以实现功能。在范例代码中，实现了一种点对点的转发机制。演示者虚拟出一些工业设备，以及一些操作员使用的客户端软件。设备与客户端软件在成功认证并登录后，需要交换数据。改变这个模块的代码，即可实现自己的功能。

说明一、本压缩包含： 1、Demo源码，位于：\Demos\G-TcpServerLibDemo\G-TcpServerLibDemo.vcproj 2、G-TcpServer模块头文件文件，位于：\G-Sockets\G-TcpServer.h（模块核心文件） 3、G-TcpServer模块Lib文件，位于：\G-Sockets\G-TcpServer.lib（模块核心文件） 4、无限制Demo exe文件:G-TcpServerLibDemo1.0.exe 二、受限制库G-TcpServer.lib说明：库文件G-TcpServer.lib是受限制的试用版本和Demo配套。 1、最大连接不能超过100 2、发送字节数不能超过128 3、不能设置0读投递 4、其他功能限制三、版本解读说明 1、版本名带T的表示是受限制的试用版，参阅二 2、版本名带bata表示非正式版 3、版本名带WChar表示支持WideChar 4、版本号以时间格式累加计数（60进1）和显示四、技术说明 1、模块包含处理线程、工作线程和看守线程。工作线程负责IO投递工作，并响应投递返回，再把接收的数据投递给处理线程，处理线程调用回调函数给应用层，以此可以在通讯层和应用层之间现实0拷贝数据的功能。模块只有一个看守线程，负责：a、响应Accept事件并投递接受队列；b、效验接受超时（即只连接不发数据）断开连接，防止空连接；c、效验空闲超时（即心跳超时）断开连接。按工作量来分，最繁重的是处理线程，其次是工作线程，最闲的是看守线程。可通过OnThread事件回调函数设置线程权限。在此线程模式下，应用层可以在回调函数里处理数据而不必再建立另外的数据处理线程池。 2、线程平衡为使连接能平衡使用处理线程，每个连接同时只有一个处理线程处理工作线程投递过来的IO返回事件并调用回调函数通知应用层。 3、收发平衡为使连接能平衡使用IO设备，每个连接同时只能投递一个读请求，并通过线程平衡机制保证接收的数据是按顺序的被处理线程处理及通过回调函数传递给应用层；同时也只能投递一个写请求，其余写请求都按顺序放在写队列里面。读写同步都使用临界段。 4、0拷贝技术接收数据0拷贝看1项；提供GTcpSvr_AllocGBuf()、GTcpSvr_FreeGBuf()和GTcpSvr_PostSendGBuf()三个函数实现发送数据的0拷贝。 5、0读投递为避免内核锁定分页内存过多，可通过设置来采用0读投递来降低吞吐性能从而实现大连接量。 6、HndData回收 HndData回收有多种方法，但额外会在收发数据这两个频率操作上增加工作量，因此尽量避免在这两个操作时做太多的工作是有必要的。模块均不采用“投递计数”或“投递链表”的方式来判断回收HndData的时机，而是一旦断线立即回收，其他未决投递继续返回时只处理IoData，不对HndData做任何写操作。同时为避免HndData刚收回来但其未决投递还没有完全返回之前就立即被利用的可能性，HndData池采用了FIFO双锁并发链表，该链表通过ExNumber值来实现在最大连接情况下HndData池还有ExNumber个数量使链表不为NULL，通过设置ExNumber数量可实现控制链表末端的HndData出列时间，在这个时间内可以保证断开刚回收的HndData的未决投递能够完全返回。 HndData池，初始时如下： HD1 + HD2 + HD... + HDMaxConnection + HDEx1 + HDEx2 + HDEx... + HDExNumber | | Head------------------------------------------------------------------Tail 达到最大连接时如下: HDEx1 + HDEx2 + HDEx... + HDExNumber | | Head---------------------------Tail 断开回收一个HndData(HD)后如下： HDEx1 + HDEx2 + HDEx... + HDExNumber + HD | | Head-------(需要T时间HD才能出列)------Tail

在游戏客户端开发过程中难免有些任务是需要另外开一个线程来执行的，这些任务的特点是会有一些阻塞操作，它的执行不能影响到游戏线程的正常执行。比如一款网络游戏的客户端，那么网络的收发最好是使用单独的线程来处理，又比如在线更新数据的操作，也最好是使用单独的线程来操作才比较合理。我在封装线程池之前想了解下UE4的多线程是怎么实现的，所以最近我看了它的源码，刚开始没有找到一个很好的入口，所以看起来云里雾里

1. 背景随着计算技术的不断发展，3纳米制程芯片已进入试产阶段，摩尔定律在现有工艺下逐渐面临巨大的物理瓶颈，通过多核处理器技术来提升服务器的性能成为提升算力的主要方向。在服务器领域，基于java构建的后端服务器占据着领先地位，因此，掌握java并发编程技术，充分利用CPU的并发处理能力是一个开发人员必修的基本功，本文结合线程池源码和实践，简要介绍了线程池和线程变量的使用。 2. 线程池概述 2.1 什么是线程池 线程池是一种“池化”的线程使用模式，通过创建一定数量的线程，让这些线程处于就绪状态来提高系

18,356

社区成员

64,214

社区内容

发帖

与我相关

我的任务

c++c语言开发语言技术论坛（原bbs）

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章