我想我知道什么是“硬”实时操作系统。它是带有调度程序的操作系统，该调度程序与应用程序程序员提供合同。应用程序为每个资源分配请求提供截止日期。 如果期限请求是可行的，则调度程序保证将在期限之前将每个资源分配给请求的应用程序。该保证足以使应用程序程序员能够推理特定请求的最大延迟和最小吞吐量。
我发现的所有关于“软”实时系统的定义在我看来都是空虚的。 维基百科说
结果的有用性在其截止日期之后降低，从而降低了系统的服务质量。
嗯 好的。按照这个标准，Windows 95是一个软实时系统，3BSD和Linux也是如此。Wikipedia不是一个很好的来源，但是接下来的两个Google热门记录并没有好得多。例如http://users.ece.cmu.edu/~koopman/des_s99/real_time/说
在软实时系统中，可以容忍很少出现的峰值负载下的性能下降。
那不是合同，那是什么都不说的幻想。
实际操作系统提供的真正的软实时担保/合同的例子有哪些？
我正在寻找以下形式的答案：
在（OS-name）中，如果程序员这样做（程序员需要做什么），则操作系统保证（系统保证什么）。
Answers:
您做对了，维基百科提供了尽可能多的信息-软实时不是形式上的表征，而是一种价值判断。表示“软实时”的另一种方式是“我希望它是实时的”，或者更准确地说，“它应该是实时的，但这太难了”。
如果您真的想以保证的形式措辞，那是尽力而为的保证，而不是特定性能的保证。
或者，引用Erlang 常见问题解答（Erlang是一种最初设计用于电话的编程语言）：
软实时是什么意思？
犬儒主义者会说“基本上什么也没有”。
（…）许多电信系统的要求[不像硬实时]严格，例如，它们可能需要“在97％的情况下数据库查找少于20ms”的统计保证。软实时系统（例如Erlang）可让您做出这种保证。
这确实提供了有用的定义。软实时表示一种设计，它针对每个单独的任务进行了优化，所花费的时间不超过特定时间，而不是针对执行所有任务所花费的总时间进行了优化。例如，软实时系统的目标是在10毫秒内完成99.9％的请求，并每秒处理100个请求，而非实时系统的目标是每秒处理200个请求，但偶尔会阻止50ms以上。硬实时性可以保证每15ms发出一个请求，无论如何。
软实时用于那些错过最后期限意味着服务质量下降但对性能要求不高的应用。多媒体和电话是一些典型的用例。每个音频或视频帧必须在时间上渲染，否则必须跳过。但是跳过一帧并不是世界末日。Erlang的设计者在其他方面也具有类似的可靠性目标：他们观察到电话交换机偶尔会掉线会更好，但是绝对要确保整个交换机都能正常工作，而不是放弃通话。尝试不惜一切代价维护连接可能会遭受灾难性的失败。
相比之下，诸如控制电动机之类的操作要求该软件永远不会错过最后期限。这有成本：总体性能通常较慢，并且只能实现相对简单的行为。另一方面，数字运算应用程序通常只关心整体性能-重要的是1000x1000矩阵的乘法速度，而不是每列的计算速度。
带有-rt（实时）补丁程序集的Linux提供了一个调度程序，该调度程序提供了一个有趣的保证，即似乎是非空的。（尽管我不清楚如何真正使用保证。）
Linux-rt SCHED_FIFO调度策略的工作方式如下：用户为每个进程分配一个优先级。（“实时”进程的优先级数字为0-99，而传统的Unix nice值-20至19映射到优先级100至139。（因此，“ 0”是“最高”优先级，而“ 139”是“最低”优先级“ 优先。）
保证是，调度程序将随时N在N处理器计算机上调度优先级最高的可运行作业。为避免内核内部的优先级反转问题，我们付出了极大的努力。当进程A变得可运行并且比其他正在运行的进程具有更高的优先级时B，A它将立即被抢占B。
但是请注意，没有给出严格的时间保证。从理论上讲，实际执行抢占的时间可能会任意长。同样，似乎有一些方法可以使低优先级的作业启动一堆长延迟的I / O。当I / O完成时，低优先级作业的中断处理程序可能会中断较高优先级的作业，这可以说是优先级反转的一种形式。
因此，所提供的有限保证是：如果有一个优先级最高的进程，则只要该进程可运行，它将获得OS可以实际提供的所有处理器资源。如果您对最高优先级进程消耗的处理器资源量有一个很好的上限，则可以计算出第二高优先级进程可以使用的资源的合理准确的估计值，依此类推。
http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler上有一篇介绍Linux实时调度程序的深入文章。
要定义“软实时”，最容易将其与“硬实时”进行比较。
随便地说，大多数人都隐含着非正式的心理模型，该模型将信息或事件视为“实时”
•是否（或在某种程度上）以明显的延迟（潜伏期）向他们表明与他们所感知的货币有关
•即，在某个时间范围内，信息或事件对他们具有可接受的令人满意的价值。
“硬实时”有许多不同的临时定义，但是在这种心理模型中，硬实时由“ if”术语表示。具体来说，假设实时操作（例如任务）具有完成期限，则所有任务完成的事件的可接受的令人满意的价值限于所有任务都满足其期限的特殊情况。
硬实时系统做出非常强烈的假设，即与应用程序，系统和环境有关的一切都是静态的，并且是先验的，例如，哪些任务是周期性的，到达时间，周期，截止日期，他们赢得了不会出现资源冲突，并且不会随着时间的推移而导致整个系统的发展。在飞机飞行控制系统或汽车制动系统以及许多其他情况下，通常可以满足这些假设，以便能够满足所有截止日期。
这种心智模型刻意且非常有用，足以涵盖硬性和软性实时性，而软性则包含在“该范围内”。例如，假设任务完成事件具有次优但可接受的值，如果
这些都是很多应用中软实时案例的常见示例。
考虑放学后接孩子的单任务应用程序。那可能没有实际的截止日期，但是根据事件发生的时间，您和您的孩子会有一些价值。太早浪费资源（例如您的时间），而太迟则具有一些负面价值，因为您的孩子可能会独自一人，并有可能受到伤害（或至少造成不便）。
与静态硬实时特殊情况不同，软实时仅对任务和系统做出最低限度的特定于应用程序的假设，并且存在不确定性。要接您的孩子，您必须开车去学校，而且上课的时间是动态的，具体取决于天气，交通状况等。您可能会倾向于过度配置系统（即，允许您希望最坏的情况是开车时间），但这又浪费了资源（您的时间，占用了家庭用车，可能会拒绝其他家庭成员使用）。
就浪费的资源而言，该示例似乎并不昂贵，但请考虑其他示例。所有军事作战系统都是实时的。例如，考虑使用导弹进行的攻击对敌方地面车辆进行飞机攻击，并对其进行更新作为目标机动。通过对目标的直接破坏性攻击，可以达到完成课程更新任务的最大满意度。但是，尝试过度配置资源以确保这一结果通常太昂贵了，甚至可能是不可能的。在这种情况下，如果导弹的打击距离目标足够近以致无法使目标失效，您可能会感到满足，但您可能会感到满意。
显然，战斗场景具有许多可能的动态不确定性，资源管理必须适应这些不确定性。软实时系统在许多民用系统（例如工业自动化）中也很常见，尽管军事系统显然是实现可接受的令人满意的价值的最危险，最紧急的系统。
实时系统的重点是“可预测性”。硬实时情况只对一种特殊的可预测性感兴趣，即，所有任务都将按时完成，该事件将实现最大的价值。该特殊情况称为“确定性”。
有可预测的范围；大多数实时系统（即软系统）具有不确定的可预测性，例如，任务的完成时间以及因此从这些事件中获得的值。一般而言，可预测性和价值因此可以尽可能地接近确定性终点，但价格可能在物理上是不可能的或过于昂贵（例如在战斗中，甚至是在接送孩子上学时）。
软实时需要特定于应用程序的概率模型（而不是普通的常客模型）的选择，因此需要用于预测事件延迟和结果值的可预测性模型。
回顾上面提供可接受值的事件列表，现在我们可以添加非确定性案例，例如
在导弹防御应用中，考虑到在战斗中进攻总是比防御具有优势，因此您更喜欢以下两种实时计算方案中的哪一种：
因为不可能完全摧毁所有敌对导弹，甚至不可能摧毁，所以请分配防御资源，以最大可能地成功截获许多威胁力最大的敌方导弹（例如，基于其目标）（由于拦截导弹数量少，因此拦截成功）可以将敌对导弹移出航道）；
抱怨这不是实时计算问题，因为它是动态的，而不是静态的，并且传统的实时概念和技术不适用，因此您没有兴趣进行软实时的R＆D。
尽管在实时计算社区中（但是在其他非计算领域中）对软实时存在各种误解，但软实时非常通用且功能强大，与硬实时相比可能非常复杂。
要直接回答OP问题：
硬实时系统可以提供确定性保证-最常见的情况是所有任务都将按时完成任务，中断或系统调用响应时间将始终小于x，依此类推。重要的事情都是静态的，并且是先验的（通常，对于硬实时系统的此类保证是一个开放的研究问题，除了相当简单的情况之外）
软实时系统不能提供确定性的保证，它旨在根据特定的应用标准，提供在当前动态情况下可行的，尽可能最佳的分析确定的概率及时性和及时性的可预测性。显然，硬实时是软实时的一个简单特例。显然，软实时的分析性不确定性保证可能非常复杂，但是在大多数常见的实时情况（包括最危险的对安全至关重要的实时情况）中，这是强制性的，因为大多数情况是动态的而不是静态的。
在我的网站real-time.org上，我对实时，硬实时，软实时，可预测性，确定性以及相关主题进行了更为精确的详细讨论。