OS-Ucos/Rtems/Vxworks/Linux基本函数接口对比

 

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信号量多进程间的互斥同步
posix信号量多线程之间的互斥同步

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

消息队列

 

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首先等待EVENTEVENT中了后再去相应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 的原优先级。这种方法只在占有资源的低优先级任务阻塞了高优先级任务时才动态的改变任务的优先级,如果过程较复杂, 则需要进行判断。

你可能感兴趣的:(OS-Ucos/Rtems/Vxworks/Linux基本函数接口对比)