The timer module is one of the key components of the Protocol server. Almost every protocol software has a timeout mechanism. In multi-threaded software, the biggest problem with the timer is to remove Asynchronization, which makes it inevitable to protect the data structure related to each session. APMs provides basic timer Management APIs. The main design objectives are as follows:
- The timer implementation must be efficient and there should be no searches or sorting in any operations related to the timer. The time complexity required for start, stop, and time-out processing must be O (1 ).
- The timer implementation must be measurable and support a long time-out (at least 24 hours or longer) with a small memory usage.
- The timer callback function must be called in serial mode to avoid maintaining the data structure related to shared sessions.
- The timer MUST be accurate.
The AMPs timer meets all of the above objectives. Its design is described below:
Amps regards the timer as a high-priority event, which is generated every k milliseconds. k is the minimum unit of time for the timer module. The default value is 1 millisecond. The system has a high-priority thread (with a higher priority than the main cyclic thread, I/O proxy, and CPU proxy). After this thread slews for K milliseconds, will wake up and send an event to the main program through the IPC Mechanism, and then continue to sleep for K milliseconds. The event manager of the main program processes this tick event with a higher priority than other events in the system. After processing any event, it checks the tick event to determine whether the event has been processed for more than K milliseconds. This method ensures that the tick event does not have to wait for other events to be processed. In addition, you can determine which events in the system have been processed for more than K milliseconds, so that application developers can discover such event processing handles and split them into multiple events smaller than K milliseconds, the timer provides an API that allows you to specify a callback function and a pointer passed in as a parameter.
The data structure of the timer contains an array divided by level. Each timer represents a digital clock, which is similar to the timer implementation concept in Linux kernel. amps has four such arrays, the first array represents milliseconds, and each element represents a tick or K millisecond. This array contains 1000/k elements, which also indicates the time of one second, it also implies that the timeout must be a multiple of K Ms. The second array represents seconds, with 60 elements, indicating a minute. Similarly, the third array represents minutes, And there are 60 elements, indicating an hour. The last array represents the hour, with 24 elements representing the time of the day. Each element of each array is a double-chain table composed of timer callback functions. Each time a tick event is generated, the tick event handle traverses the linked list stored by the current array element, call each callback function in turn, and add the following array table to 1. When the millisecond array ends, the event processing handle fills all elements of the millisecond array through the callback function under the current second array, in addition, the following table adds 1 to the second array. At this time, the callback function in the second array elements waits for the next second to arrive, and the event handle begins to add the second array. Similarly, when the second array ends, the event handle uses the callback function of the elements in the following table of the current minute array to fill all elements in the second array. The principle of other arrays is the same. In this way, the millisecond array subscript adds 1 to every tick, the second array subscript adds 1 to every second, the minute array subscript adds 1 to every minute, and the hour array subscript adds 1 to every hour. Note that the execution of callback functions is in the millisecond array. The timer mechanism is shown in:
