维护定时器.ppt

冲突链表的维护（2） 方法二： 在每个hash bucket中，新加入的定时器放在表头（无序链表） 每个时钟滴答，当前时间指针下移一个位置；如果元素所指链表非空，递减链表中每一个元素（高24位定时器值）；若某个元素为0，调用相应的ExpiryProcessing 方法二的复杂度分析 StartTimer最坏及平均延迟均为O(1) 若定时器数量nTableSize，PerTickBookkeeping的平均延迟仍为O(1)，这是因为： 每隔TableSize个时钟滴答，所有活跃定时器都做了一次减1，平均每个时钟滴答的运算次数是n/TableSize次。 如果所有定时器都哈希到一个hash bucket，那么，每隔TableSize个时钟滴答要做O(n)的工作，但在其余的每个时钟滴答内只做O(1)的工作，平均来说仍是O(1)。 若希望每个时钟滴答内所做的工作少且有界，只需令哈希表长度比需要支持的并发定时器数量大即可。 哈希函数的选择 以上复杂度分析结果对任何一种哈希函数均适用 哈希函数的选择并不重要： 哈希函数只影响PerTickBookkeeping延迟的突发性，并不影响它的平均延迟 不管采用什么哈希函数，PerTickBookkeeping的最坏情况延迟总是O(n) 因此，只需选择简单的哈希函数就可以了。 7.5 分层定时轮（Hierarchical Wheels） 为表示最长时间为100天（8640000秒）的定时器，只需使用以下4个不同时间粒度的数组： 一个长度为100的数组，每个元素表示1天 一个长度为24的数组，每个元素表示1小时 一个长度为60的数组，每个元素表示1分钟 一个长度为60的数组，每个元素表示1秒钟 所需空间： 100+24+60+60=244个存储位置 举例 设置定时器 假定当前时间是11天10时24分30秒，需设置一个时长为50分45秒的定时器： 首先计算定时器的绝对到期时间为11天11时15分15秒； 将定时器插入到小时数组中当前指针（10时）向下一个元素（11时）所指的链表中，将余数（15分15秒）存入该位置。 秒数组的工作方式 秒数组按如下方式工作： 在硬件时钟的每个滴答，秒指针加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实现： 将定时器组织在一个有序链表中，每个定时器值为距离前一个定时器到期时间的时长。 设置和取消定时器时沿链表查找，时间复杂度为O(n)。查找定时器的过程中，中断被锁定。 改进的实现： 基于哈希轮，启动、取消和维护定时器都只需常数时间，中断被锁定的时间很短 可支持几千个同时活跃的时钟 7.7 获得细粒度定时器 早期的BSD实现，定时器粒度为200ms 大多数系统的定时器精度很少有小于1ms的，而定时器粒度不可能低于定时器滴答的粒度 通过提高定时器芯片的中断频率来获得细粒度定时器，中断处理开销太大： 在500MHz的Pentium CPU上测得一次中断处理的开销约为4.5微秒 如果定时器硬件每10微秒中断一次，则中断处理开销就要占到45% 运用系统思维 整个CPU时间充满了各种转换事件，包括系统调用、异常（如缺页）、硬件中断等。 设想： 在处理转换事件的代码中加入对定时器的检查，不会增加很多开销。 但和硬件时钟中断不同的是，转换事件的发生频率不可预测。经实际测量： 转换事件之间的平均延迟在5～30微秒之间变化 超过100微秒的延迟仅有6%的发生率 最大延迟从未超过1ms 提供“软”定时器设施 放宽系统要求（P3）： 不试图实现一个总能提供微秒级定时器的“硬”定时器设施，而是实现一个经