OS-Ucos/Rtems/Vxworks/Linux,这几种OS都接触过,几乎都是一些应用层面得,下面是他们的基本函数接口对比
| 任务 |
|
uCos | INT8U OSTaskCreate ( void (*task)(void *pd), void *pdata, OS_STK *ptos, INT8U prio) | 栈, 优先级(0~63) 只支持SCHED_FIFO |
Rtems | Int rtems_task_create( rtems_name name, rtems_task_priority initial_priority, rtems_unsigned32 stack_size, rtems_mode initial_modes, rtems_attribute attribute_set, rtems_id *id ) Int rtems_task_start( task_id, (rtems_task_entry)entrypt, (rtems_task_argument)parent_id) | 栈, 优先级, SCHED_RR/ SCHED_FIFO/ SCHED_OTHER 任务NAME 任务ID
|
VxWorks | int taskSpawn( char *name, int pri, int opts, int stksize, int (*funcptr), void *pdata) | 栈, 优先级, SCHED_RR/ SCHED_FIFO/ SCHED_OTHER 任务NAME |
Linux | int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg) | 栈, 优先级, SCHED_RR/ SCHED_FIFO/ SCHED_OTHER 是否绑定、是否分离 |
| 信号量 |
|
uCos | OS_EVENT *OSSemCreate (INT16U cnt) |
|
Rtems | rtems_semaphore_create ( rtems_name name, uint32_t count, rtems_attributeattribute_set, rtems_task_priority priority_ceiling, rtems_id *id) | 优先级继承 FIFO/ PRIORITY 可以用互斥信号量实现锁功能 |
VxWorks | v2lsem_t *semBCreate(int opt, int initial_state) | FIFO/ PRIORITY 可以用互斥信号量实现锁功能 |
Linux | pthread_mutex_init(锁) pthread_cond_init
| 条件变量,做互斥,实现同步(1) |
Linux:posix | int sem_init __P ( (sem_t *__sem, int __pshared, unsigned int __value)) | 对比条件变量,比较重量级的 System v信号量多进程间的互斥同步 |
| 消息队列 |
|
uCos | OS_EVENT *OSQCreate ( void **start, INT16U size) |
|
Rtems | rtems_message_queue_create( rtems_name name, rtems_unsigned32 count, rtems_unsigned32 max_message_size, rtems_attribute attribute_set, rtems_id *id ); rtems_event_send/ rtems_event_receive | FIFO/ PRIORITY 一个TASk收到不同的消息队列,TASK首先等待EVENT,EVENT中了后再去相应EVENT收消息队列 |
VxWorks | MSG_Q_ID msgQCreate( int max_msgs, int msglen, int opt) eventSend eventReceive | FIFO/ PRIORITY 一个TASk收到不同的消息队列的处理需要和EVENT事件一起使用,或者使用PIPE |
VxWorks | PIPE |
|
Linux | POSIX消息队列 | 进程中使用 |
Linux | PIPE | 进程中使用 |
Linux | Socket | 进程中使用 |
Linux | 共享内存 | 进程中使用,除非性能有要求,一般不用 |
下面转载:
1,SCHED_OTHER 分时调度策略,
2,SCHED_FIFO实时调度策略,先到先服务
3,SCHED_RR实时调度策略,时间片轮转
SHCED_RR和SCHED_FIFO不同:
当采用SHCED_RR策略的进程的时间片用完,系统将重新分配时间片,并置于就绪队列尾。放在队列尾保证了所有具有相同优先级的RR任务的调度公平。SCHED_FIFO一旦占用cpu则一直运行。一直运行直到有更高优先级任务到达或自己放弃。如果有相同优先级的实时进程(根据优先级计算的调度权值是一样的)已经准备好,FIFO时必须等待该进程主动放弃后才可以运行这个优先级相同的任务。而RR可以让每个任务都执行一段时间。
相同点:
RR和FIFO都只用于实时任务。
创建时优先级大于0(1-99)。
按照可抢占优先级调度算法进行。
就绪态的实时任务立即抢占非实时任务。
进程通信:
也许我们很少直接使用共享内存(虽然它速度最快),实际上除非性能上有特殊要求,我更愿意采用socket或者管道作为进程间通信的方式,至于POSIX消息队列,速度和管道差不多,鉴于IPC的缺陷,不建议用消息队列。
线程通信:
同一个进程的线程之间不需要管道就可以通信了啊。(ECI:进程用PIPE、线程用消息队列,UT:进程用SOCKET、线程用消息队列)
优先级反转:
有优先级为A、B和C三个任务,优先级A>B>C。当任务A要使用共享资源S时,由于其正在被任务C使用,因此任务A被挂起,任务C开始运行。如果此时任务B等待事件到来,则任务B转为就绪态。由于任务B优先级比任务C高,因此任务B开始运行,直到其运行完毕,任务C才开始运行。直到任务C释放共享资源S后,任务A才得以执行。在这种情况下,优先级发生了翻转,任务B先于任务A运行。
解决优先级翻转问题有优先级天花板(priority ceiling)和优先级继承(priority inheritance)两种办法。
优先级天花板是当任务申请某资源时, 把该任务的优先级提升到可访问这个资源的所有任务中的最高优先级, 这个优先级称为该资源的优先级天花板。这种方法简单易行, 不必进行复杂的判断, 不管任务是否阻塞了高优先级任务的运行, 只要任务访问共享资源都会提升任务的优先级。
优先级继承是当任务A 申请共享资源S 时, 如果S正在被任务C 使用,通过比较任务C 与自身的优先级,如发现任务C 的优先级小于自身的优先级, 则将任务C的优先级提升到自身的优先级, 任务C 释放资源S 后,再恢复任务C 的原优先级。这种方法只在占有资源的低优先级任务阻塞了高优先级任务时才动态的改变任务的优先级,如果过程较复杂, 则需要进行判断。