linux - 公平:在哪里可以更好地处理？

我想在这里分享我的多道程序设计实践经验。
昨天我写了一个多道程序。对可共享资源的修改放在受P（互斥）和V（互斥）保护的关键部分下，这些关键部分代码放在一个公共库中。库将由并发应用程序（我自己的）使用。
我有三个应用程序将使用库中的公共代码并独立完成它们的工作。

 my library
 ---------
 work_on_shared_resource
 {
  P(mutex)
  get_shared_resource
  work_with_it
  V(mutex)
 }
     ---------

 my application
 -----------
 application1
 {
   *[
      work_on_shared_resource
      do_something_else_non_ctitical
    ]
 }


 application2
 {
   *[
      work_on_shared_resource
      do_something_else_non_ctitical
    ]
 }


 application3
 {
   *[
      work_on_shared_resource
    ]
 }

 *[...] denote a loop.
 ------------

我不得不在Linux操作系统上运行这些应用程序。多年来，我一直在想，操作系统应该公平地调度他下运行的所有进程。换言之，它将给所有进程，它们的资源使用派同样好。
当前两个应用程序投入运行时，它们运行得非常好，没有死锁。但是，当第三个应用程序开始运行时，总是第三个应用程序获得了资源，但是由于它没有在非关键区域执行任何操作，所以当其他任务正在执行其他操作时，它更经常获得共享资源。因此，发现其他两个应用程序几乎完全停止。当第三个应用程序被强制终止时，前两个应用程序将一如既往地继续工作。
我想，这是一个饿死的案例，前两个应用程序不得不饿死。
现在我们如何确保公平？
现在我开始相信操作系统调度程序是无辜和盲目的。这取决于谁赢得了比赛；他得到了最大的CPU和资源。
我们是否应该在图书馆的关键章节代码中保证资源用户的公平性？
还是让申请者来决定，让他们自由而不是贪婪，以确保公平？
据我所知，添加代码以确保公共图书馆的公平性将是一项艰巨的任务。另一方面，相信申请也永远无法保证100%的公平。在使用共享资源后只执行很少任务的应用程序将赢得这样一场竞赛：作为在使用共享资源后执行大量处理的应用程序，它们将永远处于饥饿状态。
在这种情况下，最佳做法是什么？我们如何确保公平？
真诚的，
斯里尼瓦斯纳亚克

最佳答案

为了保证互斥锁的平等共享或检测并避免死锁，人们已经对撤销互斥锁的所有权进行了研究。然而，这真的是杀伤力太大了，不值得这么做，特别是因为它打开了一个全新的蠕虫罐头，比如如果程序在某些计算过程中失去了对资源的所有权，它应该如何运行。这实际上取决于应用程序，以确保其各个线程之间的公平性，并以不会死锁的方式消耗资源。
我应该指出，还有另一种选择，尽管种类略有不同，那就是使用并行编程的消息传递风格。通过消息传递，同步在通信中都是隐式的；不需要显式同步，这有助于避免此类错误。

关于linux - 公平:在哪里可以更好地处理？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2825651/