这是一个有关时间片分配的故事
从前，在名为os的森林里有两个进程，一个名兔子，它运行起来cpu一直在转；一只名乌龟，它经常要与其它设备交互，平均每个时间片只有1%在运算，而剩下的99%都在阻塞
某天，os将乌龟与兔子调度到了同一个cpu上，它们相约同时开始计算一个很大的哈希，比一比谁先返回。
起初，兔子和乌龟都在最高优先级的队列中，兔子、先拿到了一个时间片。几毫秒的时间里cpu飞快地运转，很快这个哈希值就要算完了，可惜时间片结束了，因为兔子一直在占用cpu，它的优先级被降低了一位。
接下来轮到了乌龟，乌龟每算几个字符都要阻塞很久，这不，刚才阻塞中恢复，时间片就结束了。因为cpu使用时间不长，乌龟的优先级没有降低。
下一个时间片到来了，兔子正摩拳擦掌准备一鼓作气算完，却发现os把时间片分给了乌龟——乌龟现在的优先级比兔子高
接下来兔子等啊等，希望某一次时间片结束时乌龟还在阻塞，这样它就能一举追回优势，然而乌龟慢吞吞地行动背后有着精妙的设计，每次时间片结束时都恰好刚从阻塞中恢复，开始cpu计算，于是时间片一直被把持着
兔子眼巴巴地盯着乌龟，就在它已接受即将饿死的事实时，突然，新一轮调度完成，兔子获得了一个时间片，惊喜中兔子奋力一冲，算完了这个哈希——但回头一看，进程表里哪里还有什么乌龟，它已经算完哈希结束了！
就像原版的故事中，兔子输掉不是因为跑得快，而是莫名其妙的贪睡设定一样，本文中兔子输掉也不是因为它cpu密集，而是简单的MLFQ策略确实存在着这样的漏洞，所以后续设计师们增加了更复杂的策略来避免，但在故事发生时，这还都不存在
望着空荡荡的进程表的兔子在想什么呢？快并不代表拥有，久等并不意味着机会，它说，它要学着顺应操作系统的规则