第七章维护定时器.pptVIP

秒数组的工作方式 秒数组按如下方式工作： 在硬件时钟的每个滴答，秒指针加1 如果当前元素所指链表非空，对链表中的每个元素执行ExpiryProcessing 其它三个数组的更新 为推动分层定时轮，系统中总有以下时钟： 一个60秒的定时器：用来更新分钟数组 一个60分钟的定时器：用来更新小时数组 一个24小时的定时器：用来更新天数组 以60秒定时器为例： 每当60秒定时器到期，将当前分钟指针下移1个位置，为分钟指针指向的定时器（链）执行ExpiryProcessing，重新插入一个60秒定时器 时间到达指定的小时 当时间到达11时（此时小时指针指向元素11，分钟指针和秒指针都指向各自数组的元素0）： ExpiryProcessing检查链表中的元素，获得剩余时间15分15秒 将定时器移动到分钟数组当前指针（0分）向后15个元素（15分）的链表中，存入余数15秒 时间到达指定的分和秒 当分钟指针到达第15个元素时（此时秒指针指向元素0）： ExpiryProcessing检查链表中的元素，获得剩余时间15秒 将定时器移动到秒数组，放入当前秒指针（0秒）向后15个元素（15秒）的链表中 当秒指针到达第15个元素时： 定时器到期，执行用户的ExpiryProcessing 7.6 BSD实现的定时器 原先BSD中实现的定时器： 将定时器组织在一个有序链表中，每个定时器值为距离前一个定时器到期时间的间隔 每个时钟滴答，只对表头元素进行递减，减为0则去掉表头，执行超时处理 设置和取消定时器时沿链表查找，时间复杂度为O(n)。查找定时器的过程中，中断被锁定 改进的实现： 基于哈希轮，启动、取消和维护定时器都只需常数时间，中断被锁定的时间很短 可支持几千个同时活跃的时钟 7.7 获得细粒度定时器 早期BSD中实现的定时器，时间粒度为200ms 大多数系统的定时器精度不小于1ms，如何获得更细粒度的定时器，比如10微秒？ 通过提高定时器芯片的中断频率来获得细粒度定时器，中断处理开销太大： 在500MHz的Pentium CPU上测得一次中断处理的开销约为4.5微秒 如果定时器硬件每10微秒中断一次，则中断处理开销就要占到45% 运用系统思维 整个CPU时间充满了各种转换事件，包括系统调用、异常（如缺页）、硬件中断等 设想： 在处理转换事件的代码中加入对定时器的检查，不会增加很多开销 但和硬件时钟中断不同的是，转换事件的发生频率不可预测。经实际测量： 转换事件之间的平均延迟在5～30微秒之间变化 超过100微秒的延迟仅有6%的发生率 最大延迟从未超过1ms 提供“软”定时器设施 放宽系统要求（P3）： 不试图实现一个总能提供微秒级定时器的“硬”定时器设施，而是实现一个经常能提供10微秒定时器的“软”定时器设施 为限制软定时器设施的误差，可以增加一个每隔1ms中断一次的硬件时钟中断 许多网络应用可以从软定时器受益，如使用快速重传进行错误恢复时，多数情况下可以很快（小于1ms）进行 7.8 小结 定时轮： 无论有多少个定时器，都可将定时器实现的开销降至常数，这使得一个定时器设施可以支持非常多的定时器 软件定时器： 可以减少由PerTickBookkeeping引起的操作系统开销，使得一个定时器设施在多数情况下可以提供细粒度的定时器 第七章 维护定时器 7.1 定时器 网络协议大量使用定时器实现与时间有关的功能 当以下任一情况发生时，定时器模块存在性能问题： 定时器算法由CPU实现：每一个时钟滴答都要中断CPU。若时钟精度在微秒量级，中断处理开销很大（一次中断处理开销为几微秒） 要求细粒度定时器（如微秒量级）：即使不用CPU处理每个时钟滴答的中断，定时器操作（如启动、终止等）的延迟必须很小 同时活跃的定时器数目很大：查找和操作定时器的延迟必须很小 当网络速度提高时，以上问题更突出： 定时器精度相应要提高：比如需要更细粒度的定时器测量RTT 定时器操作速度要提高：包速提高了，每个包都要涉及定时器操作 定时器模块的组成 StartTimer (Interval, RequestID, ExpiryAction)： 启动一个定时器，定时器在Interval个时间单位后超时 ExpiryAction：指出超时后采取的动作，如调用一个指定的处理例程 StopTimer (RequestID)： 利用客户和RequestID信息定位定时器，并终止定时器 PerTickBookkeeping： 每隔1个定时器滴答（取决于定时器的粒度），检查是否有定时器超时；若有，调用ExpiryProcessing例程 ExpiryProcessing： 执行StartTimer()中指定的ExpiryAction 前2个例程由客户调用，后两个例程由定时器管