首先想说一句别把麻烦管理员我的帖子转到其他地方，因为这里的人群旺！！高手多！！       进来发现keil自带的实时操作系统RTX(由于ARM,RTX-51是针对51的)的资源非常丰富，集成了TCP/IP、CAN、USB、FS等协议栈。       因为我以前有UCOS-II的基础，所以很快就看完了，比较而言： 1、RTX在调度方式上增加了 时间片轮转的方式 2、RTX的邮箱集成了UCOS的邮箱和消息队列的功能，但是没有“广播”的功能 3、RTX的软件定时器功能一般般。可能是用的不多的原因。 4、UCOS的用户群庞大，资料丰富  ，但是需要自己移植其他协议栈，如LwIP等，RTX资源丰富。          我在调试RTX的邮箱（KeilARMRLRTXExamplesMailbox）这个例子的时候遇到不解的问题： 这个例子非常简单，由于演示邮箱的基本用法，具体是这样的：        建立的两个任务：一个是邮箱发送任务，发送三条消息，然后删除自己。另一个是邮箱接收任务，在无限循环中等待邮箱消息并处理（即调用os_dly_wait()函数挂起任务直到消息到来），两个任务都是同样的优先级，使能了时间片轮转的功能，在邮箱发送任务中，每调用一次 os_mbx_send(邮箱发送函数) 之后都会调用 os_dly_wait(系统延时函数)来调度任务，以便让邮箱接收任务处理发送任务发送的消息。这个没问题。 我在单步执行的时候观察，在任务发送任务中切换到接收的任务的时候是在执行os_dly_wait(系统延时函数) 时， 不是在执行完os_mbx_send(邮箱发送函数) ，这是正确的因为两个任务是同样的优先级。刚刚发送完消息之后接收任务只是处于“就绪态”当调用os_mbx_send()后交出了执行权。       然后我就想，那我要是改变两个任务的优先级，让接收任务的优先级比发送任务邮箱级高，那么现象应该是：在发送任务执行完  os_mbx_send(邮箱发送函数) 后就应该发生调度，在ucos中是这样的，因为这就是优先级抢占的基本思想。但是奇怪的是：这样改变优先级后，无论是执行os_mbx_send()还是os_dly_wait()都不会产生任务调度，也就是说发送消息“丢失了”。               然后我尝试改变两者优先级为：发送任务高，接收任务低，现象正确。       请教各路高手 这是为什么？发送任务优先级低，接收任务优先级高，就不会产生任务调度。。。。。。。                         此帖出自小平头技术问答