To make quick moves, consider using pointers to transmit data between threads. Anyway, all threads run in the same process space, and the image is a plane, this is also a serious problem. All worker threads areTIOCPWorkUnitPool <class _ TworkUnit = TPack <int>Obtain the data to be processed, which is called the work order metapool (haha, this is the name of the kid, think what the worker thread should be called? ). The pool hasStd: list <__ TworkUnit>Member to save the unit of work to be processed. The default value isTPack <int>, All data (default value:TPack <int>) First fill inListThen, the worker thread can start fromListObtain the work unit. The pool has a default size and a maximum limit. When the worker units to be processed flood in, if the worker threads cannot work diligently or cope with the problemsListInsufficient space, the worker pool of the work order increases by itselfListUntilListThe size has reached the limit. This method can also achieve load restrictions. Because the metadata of each work order is different, the worker thread completion time varies, andListIt is relatively fixed (meaning there is no data deletion operation), so two moreHash_map, An indicationListUsed unit, an indicatorListUnused units. In this way, fill directly from the indicator of unused spaceHash_mapTo fill in the data and move the data toHash_map. When processing is completed, the opposite action is performed, which only saves the trouble of deleting data.
Now you can create an IOCP handle object namedTIOCPHandle <class _ TworkUnit>, The object holdsTProcessInfoUsed to obtain resource usage information, A HANDLE,Indicates An IOCP with two pools:TIOCPWorkUnitPool <__tworkunit>Used to save the worker units processed by the HANDLE,TIOCPWorkUnitPool <OVERLAPPED>Used to save OVERLAPPED data. When an IOCP request is sentHEvent of OVERLAPPEDMember pointingTIOCPWorkUnitPool <__tworkunit>A unit in the pool.
The system allocates the working thread according to the IOCP request. Therefore, an IOCP thread is also required:TIOCPThread <__tworkunit>: public TObject, The thread class is _BeginthreadexEncapsulation, holdingTIOCPHandle. There are three pure virtual methods:
Void initialize (): used when the thread body starts running. It is used by the derived class to initialize its own environment.
Void uninitialize (): used when the thread body ends. It is used by the derived class to clean up its own environment.
Void process (DWORD compley, _ TWorkUnit * workunit): used to receive work order elements for customized work unit processing.
Of course, the above three methods can also be implemented through the event handle method. However, the pure virtual method requires an implementation of the derived class, which has a alerting effect.
Then, it is the basis for implementing the Dynamic Adjustment Mechanism: IOCP thread pool, namedTIOCPThreadPool <__ TworkUnit, _ TIOCPThread>, This class holdsHash_map <thread ID ,__ TIOCPThread>To manage the IOCP thread pool.
On the basis of the IOCP thread pool, you also need to establish a thread to monitor the IOCP working status. This thread is based onTTimerThreadAdjust the IOCP thread pool according to the resource usage of the process at the specified time, increase or decrease the working thread, and name itTIOCPDaemonThread <__ TworkUnit, _ TIOCPThread>: public TTimerThread.
TIOCPDaemonThreadHolds the IOCP thread pool and is able to manage itself.
Finally, it should be part of the drama,TIOCPModel <__tworkunit, _ TIOCPThread>: public TObjectThis class completes the final encapsulation of IOCP.TIOCPModelHold oneTIOCPDaemonThread, OneTIOCPHandleAnd hasTOnBeforeIOCPProcessEvent, used for the final judgment before the work unit is processed.