响应时间
T响应时间 = T首次运行 - T到达时间
引入响应时间的原因：如果使用STCF的调度方式，可以使周转时间最短，但是，如果短任务很多，则没有长任务执行的机会，对长任务来说很“不公平”
轮转
轮转的思想：设置一个时间片，一个进程使用完一个时间片后，切换到下一个进程。
使用轮转算法，执行时间长的任务也有机会尽快的运行，从而较长的任务的响应时间也可以变短。
时间片长度必须是时钟中断周期的倍数。（任务的切换依赖于时钟中断，时钟中断将CPU的控制权交给操作系统）
这看起来又是一个完美的算法，是不是忽略了什么？时间片的长度是多少？
任务切换时，需要进行上下文切换，这是一部分时间成本。如果时间片太短，频繁的上下文切换会占用大量的时间；如果时间片太长，则响应时间也会变长。所以，时间片具体的长度，需要权衡。
轮转的周转时间
如果只考虑响应时间，在时间片合适的情况下，轮转是很好的算法。
现在，再来讨论一下轮转的周转时间
| 进程编号 | 到达时刻 | 执行时间 |
|---|---|---|
| 0 | 0 | 30 |
| 1 | 0 | 30 |
| 2 | 0 | 30 |
暂时不考虑上下文切换的时间成本
如果轮转时间为10，且每一个进程被调度的概率相同，则可能会有下面的运行情况：
| 时刻 | 0 | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 |
|---|---|---|---|---|---|---|---|---|---|
| 运行的进程 | 0 | 1 | 2 | 0 | 1 | 2 | 0 | 1 | 2 |
| 进程编号 | 完成时间 |
|---|---|
| 0 | 70 |
| 1 | 80 |
| 2 | 90 |
平均周转时间 = （70 + 80 + 90）/3
如果不使用轮转，平均周转时间 = （30 + 60 + 90）/3
可见，如果要考虑周转时间，轮转并不是一个好的算法