我想知道哪些API可以避免以下问题。
回到我旧的CS课程的操作系统讲座，主题是多进程调度和并发I / O.以下是讲师给出的一个例子：
两个过程，X和Y有一些工作要做。有一个处理器/总线/无论如何，调度程序在天真地分配X和Y之间的时间片，如下所示：
这被描述为“公平”，但在我看来非常不公平。考虑这个方案下的两个案例
如果X和Y各占10秒，现在两者都需要20秒。
如果X需要10秒而Y需要100秒，则X需要20秒，Y需要110秒。
如果调度程序只是“完成所有X然后全部Y”那么在第一种情况下X将花费10秒而Y将需要20秒;在第二种情况下，X将需要10，而y将需要110。
如何让一个人变得更好，一个人更糟糕的制度是一个好主意？ “公平”系统有利的唯一论据是，如果我们在X之前做了所有的Y，那么一个小工作X将被大工作Y推迟，我们需要保持这两个工作“响应”。
对于第二种情况，我的一部分看到了自然的“最佳”方式，因为要说“X小10倍，因此没有任何明确的偏好，它应该得到10倍于Y的倍数”。 （这有点像在行驶之前给行人提供正确的道路，因为它们减少了对道路的压力，但我离题了。）在这个方案下，X在11秒内结束，Y在110秒内结束。现实世界的后果：即使在后台发生大量文件复制，我的mp3加载和播放也没有明显的额外延迟。
显然，有一整套战略可供使用，我不想争论任何特定战略的适用性，我的观点是： 所有这些战略都需要了解工作的规模。
那么，是否有操作系统API（Linux，甚至是Windows）允许用户指定操作所需工作量的提示？
（NB你可以声称磁盘I / O隐含地包含了这个，但是while(not_done){read_chunk();}会使它变得毫无意义 - 我想到的那种API会在文件打开时指定兆字节，在创建时创建时钟周期或者沿着这些方向的东西。）
答案 0 :(得分：1)
如果所有任务代表的工作在运行完成之前没有任何价值，那么最好的方法是按某种顺序运行所有工作，以便最大限度地降低其他事物（或人们）不得不花费的成本。等他们在实践中，许多任务代表一系列可能具有某些个体价值的操作，因此如果两个任务各占10秒，那么在10秒标记处完成两个任务可能比完成一个任务和一个任务更好甚至没有开始。特别是当任务正在生成由另一台机器执行的下游过程所需的数据时，并且下游过程将能够在它接收到的数据超过其处理的任何时间执行有用的工作。如果部分工作需要向某人展示实际发生的有用事情，那也是有些道理。观看进度条在20秒内计数的用户不太可能比进度条甚至没有进入10秒钟的人感到不快。
答案 1 :(得分：0)
＆＃34; fair＆＃34;中的唯一参数系统的优势在于，如果我们在任何X之前完成所有Y，那么一个小工作X将被大工作Y延迟，我们需要保留这两个工作并且＃34;响应＆＃34;。
这正是理由。公平的调度是公平的，因为它倾向于分配计算时间，因此在要求它的过程中平均延迟。
那么，是否有操作系统API（Linux，甚至是Windows）允许用户指定操作所需工作量的提示？
批处理系统可以做到这一点，但是，正如您自己总结的那样，这需要了解手头的任务。 Unix / Linux具有nice命令，该命令使进程的优先级较低;让多任务计算机上任何长时间运行的，受CPU限制的进程都是“好的”＃34;这是一个好主意。所以它不会阻碍简短的交互式任务。 ionice对IO优先级执行相同的操作。
（此外，自20世纪70年代早期以来，Unix调度程序动态地提高了进程的优先级，这些进程没有＆＃34;吃掉它们的切片，因此交互式进程获得高CPU优先级并且在没有CPU限制的情况下保持响应那些把握一切的人。请参阅Thompson和Ritchie关于Unix的早期论文。）
答案 2 :(得分：0)
在常见的操作系统中，您通常不关心任务的延迟，但是您尝试最大化吞吐量 - 在110秒内X和Y都将完成，周期。当然，有些进程可以是交互式的，因此操作系统会在进程之间进行上下文切换的额外开销，以保持计算错觉。
正如您所说，任何应该最小化任务完成时间的策略都需要知道需要多长时间。如果任务不仅仅是复制文件，这通常是一个问题 - 这就是为什么有时某个应用程序中的进度条达到99％并且在最后几件事情中停留一段时间的原因。
但是，在实时操作系统中，您通常必须知道任务的最坏情况执行时间或某个截止日期，直到任务必须完成 - 然后您有义务提供此类“提示”。然后，调度程序必须进行更智能的调度（此外，如果存在一些锁或依赖项），在多处理器上，该过程有时是NP完全的（然后调度程序使用一些启发式算法）。
我建议您阅读有关RTOS，最早截止时间优先调度和速率单调调度的内容。