实时操作系统是保证在一定时间限制内完成特定功能的操作系统(执行时间的确定性是实时操作系统最根本的,其代价往往就是吞吐量低)。实时操作系统有硬实时和软实时之分,硬实时要求在规定的时间内必须完成操作,这是在操作系统设计时保证的;软实时则只要按照任务的优先级,尽可能快地完成操作即可。
应用场景:汽车安全气囊的弹出
实时任务调度器是实时操作系统的一个必选项,但不代表只要设计出来一个实时调度器就足够了。事实上设计一个实时调度内核并不是一个多么复杂的任务,实时操作系统的特性是在整个操作系统的设计思路上都要时刻关注实时性。
1. 实时的消息、事件处理机制。
常规的操作系统中,消息队列都是按照FIFO(先进先出)的方式进行调度,如果有多个接受者,那么接受者也是按照FIFO的原则接受消息(数据),但实时操作系统会提供基于优先级的处理方式:两个任务优先级是分别是10和20,同时等待一个信号量,如果按照优先级方式处理,则优先级为10的任务会优先收到信号量。
2. 提供内核级的优先级翻转处理方式
实时操作系统调度器最经常遇到的问题就是优先级翻转,因此对于类似信号量一类的API,都能提供抑止优先级翻转的机制,防止操作系统死锁。
3. 减少粗粒度的锁和长期关中断的使用
这里的锁主要是指自旋锁(spinlock)一类会影响中断的锁,也包括任何关中断的操作。在Windows和Linux的驱动中,为了同步的需要,可能会长期关闭中断,这里的长期可能是毫秒到百微秒级。但实时操作系统通常不允许长期关中断。
对于非实时操作系统来说,如果收到一个外部中断,那么操作系统在处理中断的整个过程中可能会一直关中断。但实时操作系统的通常做法是把中断作为一个事件通告给另外一个任务,interrupt handler在处理完关键数据以后,立即打开中断,驱动的中断处理程序以一个高优先级任务的方式继续执行。
4. 系统级的服务也要保证实时性
对于一些系统级的服务,比如文件系统操作,非实时系统会缓存用户请求,并不直接把数据写入设备,或者建立一系列的线程池,分发文件系统请求。但实时系统中允许高优先级的任务优先写入数据,在文件系统提供服务的整个过程中,高优先级的请求被优先处理,这种高优先级策略直到操作完成。
这种设计实际上会牺牲性能,但实时系统强调的是整个系统层面的实时性,而不是某一个点(比如内核)的实时性,所以系统服务也要实时。
由于应用场景的差异,会出现有些用户需要实时性的驱动,有些用户需要高性能的驱动,因此实时操作系统实际上要提供多种形式的配置以满足不同实时性需求的用户。
5. 避免提供执行时间不确定的API
多数实时操作系统都不支持虚拟内存(page file/swap area),主要原因是缺页中断(page fault)会导致任务调度的不确定性增加。实时操作系统很多都支持分页,但很少会使用虚拟内存,因为一次缺页中断的开销十分巨大(通常都是毫秒级),波及的代码很多,导致用户程序执行的不确定性增加。
实时操作系统的确定性是一个很重要的指标,在某些极端场景下,甚至会禁用动态内存分配(malloc/free),来保证系统不受到动态的任务变化的干扰。
6. 提供针对实时系统调度的专用API
比如ARINC 653标准中就针对任务调度等作出了一系列的规定,同时定义了特定的API接口和API行为,这些API不同于POSIX API,如果实时系统要在航空设备上使用,就可能需要满足ARINC 653的规范。
7. 降低系统抖动
由于关中断等原因,通常情况下,操作系统的调度器不会太精确的产生周期性的调度,比如x86早期的默认60的时钟周期(clock rate),抖动范围可能在15-17ms之间。但一个设计优秀的实时操作系统能把调度器的抖动降低到微秒甚至百纳秒一级,在像x86这种天生抖动就很大的架构上,降低系统抖动尤其重要。
8. 针对实时性设计的SMP和虚拟化技术
SMP(多核)场景的实时调度是很困难的,这里还涉及到任务核间迁移的开销。针对SMP场景,多数实时操作系统的设计都不算十分优秀,但比起普通操作系统来说,其实时性已经好很多了。
同时实时操作系统的虚拟化能从hypervisor层面上提供虚拟机级别的实时调度,虚拟机上可以是另外一个实时系统,也可以是一个非实时系统。
标签:实时性,优先级,中断,什么,RTOS,实时,实时操作系统,API From: https://www.cnblogs.com/god-of-death/p/17768411.html