由于请求出队列的过程涉及大量的实时排序调整，因此服务器在生成dmClock- Server队列时，会基于 QoS的3个时间标签构造 3 棵完全二叉树，每棵二叉树的节点为各个 Client 请求子队列，节点在二叉树中的位置取决于其Client请求子队列队首元素的时间标签，构造规则是父节点的时间标签小于子节点。
请求入队列的执行流程如图3-13所示。若某个Client向Server发送请求，如果 Server中该 Client 的请求子队列中不存在未处理的请求，或子队列并不存在（即新来了一个Client，需要新创建子队列），则不仅需要让请求进入队列，还需将Client加入标签二叉树中，并依据标签时间的大小将其调整到正确位置。如果该Client的请求子队列中存在未处理的请求，则直接将该请求插入队列尾部即可。
图3-13 请求入队列的流程
请求出队列的执行流程如图3-14所示。先进入预留时间标签阶段，取预留标签二叉树的 root 节点请求队列，判断其队首元素的预留时间标签是否满足出队条件，若满足，则使 root节点队列的队首元素（req）出队列（并调整该节点在预留二叉树中的位置，同时也要调整该root节点对应 Client 的子队列在权重二叉树和上限二叉树中的位置）；否则进入基于上限和权重时间标签阶段，从上限二叉树的 root节点开始，依次开始判断节点队列的队首元素的上限时间标签是否满足出队条件，将满足出队条件的请求的ready位标记为true，再依据权重时间标签大小将权重二叉树中队列队首元素的ready位被标记为true的节点调整到合适位置，让位于权重标签二叉树root 节点的队首元素出队列，最后再去调整该 Client 在权重、上限、预留标签二叉树中的位置。
图3-14 请求出队列的流程
下面以实例形式分析 dmClock算法执行过程。
如表3-3所示，假设某分布式系统中有5个Client，这些Client的基准时间都为 to=0.0，每个Client的请求队列中有两个请求，QoS模板设置为[r，l，w]，每个请求都以1/r， 1/l，1/w为间隔打标签，若当前时间T=0.024s，请求出队列。
表3-3 案例示例数据
|
client |
QoS |
request1 |
request2 |
||||
R<i，1> |
L<i，1> |
P<i，1> |
R<i，2> |
L<i，2> |
P<i，2> |
||
1 |
[20，40，5] |
0.05 |
0.025 |
0.2 |
0.1 |
0.05 |
0.4 |
2 |
[10，30，3] |
0.1 |
0.033 |
0.333 |
0.2 |
0.066 |
0.666 |
3 |
[30，50，2] |
0.033 |
0.02 |
0.5 |
0.66 |
0.04 |
1 |
4 |
[40，60，1.25] |
0.025 |
0.017 |
0.8 |
0.05 |
0.034 |
1.6 |
5 |
[70，100，4] |
0.014 |
0.01 |
0.25 |
0.028 |
0.02 |
0.5 |
（1） 构造reservationtag、limittag及weighttag二叉树过程（请求入队列的过程），
见图 3-15～图 3-17。
图 3-15构造reservatontag＿叉树过程
图 3-16构造 mttag＿叉树过程
图 3-17构造 we ghttag＿叉树过程
（2） Constraint-based阶段（请求出队列的第一阶段），见图3-18～图3-20。
图 3-18请求在 Constrant-based 阶段出队列- 预留标签＿叉树调整过程
图 3-19 请求在Constrant-based 阶段出队列- 上限标签＿叉树调整过程
图 3-20 请求在 Constrant-based 阶段出队列- 权重标签＿叉树调整过程
（3） Weight-based阶段请求出队的过程，见图3-21～图 3-24。
图 3-21 找出满足出队条件的Cent
图 3-21找出满足出队条件的 Cent(续)
图 3-22请求在 weght-based阶段出队列- 权重＿叉树的调整过程
图 3-23请求在 weght-based 阶段出队列- 上限时间标签的调整过程
图 3-24请求在 weght-based 阶段出队列- 预留标签时间的调整过程