同样的，rt-thread在main中调用了rtthread_startup(),并可以看出rtthread_startup()调用了启动调度函数rt_system_scheduler_start();并随后给出注释/* never reach here */，也就是说启动器一旦调度成功，是不会也不能返回的（除非所有的任务都结束了）。
也就是说rt-thread的main函数也是不会也不能返回的。
3.其它2个我没有细看，但有理由相信（或请“安”给出一个不相信的理由），COOCS和MQX的实现机理和上述UC/OS和TR-THREAD一样：即，main是不会也不能返回的。
通过查看可知，貌似只有RTX和FreeRTOS有把main作为任务函数的配置项。
我理解就是ST的修改没有问题，freertos的意思是，可以直接在调用其他的任务以后，继续使用while(1)来运行。其他的系统，main一般都是调用一些其他的任务就结束，后面没有while(1)。
1.根据邵贝贝的《嵌入式实时操作系统uc/os-2》(第二版），3.13节（P113)： UC/OS-II的启动，其中指出了：
“多任务的启动是通过调用OSStart()实现的。”
书中给出了在main中调用OSStart()的示例，而OSStart()又调用了OSStartHighReady()，书中给出了解释：
“OSStartHighReady()将永远不返回到OSStart()。”
我没有在该书和UC/OS的官方网站上找到不在main中调用OSStart()的程序或说明。
也就是说在UC/OS中，main将不会也不能返回！
2.根据rt-Thread官方最新代码，从gitHub中获知：
http://github.com/RT-Thread/real ... lications/startup.c
同样的，rt-thread在main中调用了rtthread_startup(),并可以看出rtthread_startup()调用了启动调度函数rt_system_scheduler_start();并随后给出注释/* never reach here */，也就是说启动器一旦调度成功，是不会也不能返回的（除非所有的任务都结束了）。
也就是说rt-thread的main函数也是不会也不能返回的。
3.其它2个我没有细看，但有理由相信（或请“安”给出一个不相信的理由），COOCS和MQX的实现机理和上述UC/OS和TR-THREAD一样：即，main是不会也不能返回的。
通过查看可知，貌似只有RTX和FreeRTOS有把main作为任务函数的配置项。
1.你所理解的“结束”不能拿来误导众人，自己娱乐就好了。
2.你所谓的“即便是写了while(1)，从代码流程上看是会进入while处理”（但愿你没有写错且不是你自己娱乐用的句子），是错误的！
你还是未能理解到底哪个是正确的！你到底错在了什么地方！
你的理解停留在了如果有while(1)那么main就结束不了，这个是狭隘且错误的！因为在main中程序是进入不了while(1)的，这跟有没有while(1)都没什么卵用！有while(1)进入不了，没有while(1)，main也不会退出！
那main为什么会退出不去呢？是因为OSStart()（或其他RTOS中表示启动调度的API）是永远不会返回的（除非所有任务都返回了，这种情况程序员是不会故意而为的）！
那main中到底应不应该出现一个while(1)（或者其它任何表示死循环的语句）呢？当然有必要（但不是必须），因为这是预防程序出现错误，万一（注意是万一）从OSStart()返回了，不至于调试代码时不知道程序去哪了？OSStart()万一退出，main函数也就退出了，此时程序返回到重启向量中（一般重启向量的最后一条语句是跳往main函数），PC中已经不存在有意义的指向了，此时系统终止运行。如果main的最后有一个无线循环，那么起码程序员调试时会知道，哦，原来从OSStart()返回了，此时应该注意所有的任务函数是不是有问题。
就是想看看MAIN到底是不是做为一个任务被调度了而已
本来系统就是单线运行的，这里把任务强制为是平行运行的吧。
那么main只是一个开始的入口，开始后程序便在调度器、任务、中断中来回的切换，永远无法从main中的一个函数中退出（即无法从osKernelStart()中退出，除非你的任务函数会退出且当前所有任务函数都退出了）。
这个时候的现象就是：在各任务函数中来回的切换，这个切换是由调度器实现的，调度器是一个异常中断，用户的常规中断也会打断任务的执行。总之程序无法从osKernelStat()中返回。
不是特别规范的，可以这么理解：
main()
{
...
switch(xxx){
case 1:
func1();
schedule();
continue;
case 2:
func2();
schedule();
continue;
......
}
while(1)
{
}
}
造成不同xxx的值是由调度器来修改的，当然RTOS更加复杂，在进入每一个func()时，都需要保存旧的并更新为新的上下文，且各个函数的任务栈都是独立的。这里只是个简单的类比。
你说main怎么会是一个任务呢（main的栈包含了所有任务的栈、且一直在运行中）？
回复楼上两位：其实FREERTOS手册上都说了，MAIN可以做为一个任务参与调度，只是不知道ST对它们做了怎么的修改，我还没有搞清楚
main函数是不能结束的！否则系统就停止了。
main函数进入osKernelStart()就不会返回了，之所以留while(1){}是因为不至于真出现问题后，调试时出现无法定位而留的。
找了一通资料，发现如下几点供讨论：
1. MAIN作为任务调度，会产生一些副作用，所以ST在改写的时候将这一特性去掉了，也就是说，在ST的RTOS里，MAIN是不能作为任务供调度的。
2. 研究了一下KEIL的RTX，由于这个组件是闭源的，所以内部特征没法跟踪，只不过RTX提供了一个OSKERNELINITIALIZE()函数，而ST提供的该函数是空的，会不会这个函数里面有玄机，存疑中？
3. ST为了统一一些定义，尽管它屏蔽了MAIN作为任务的可能，但默认将OSFEATURE_MAINTHREAD的值设置为1，也就是说，这个特性只是一个摆设，根本不起作用！
供讨论
根据《The Definitive Guide to Arm Cortex-M3 and Cortex-M4 Processors》，19.3节，P613的内容看来，main作为任务函数被调度，是由于在进入main之前（即在复位向量中已经对RTX做了初始化，把main作为一个任务函数，并启动调度器），RTX只是一个独立的中间件，用户在main任务中可以初始化硬件、初始化并创建其它任务，如果已经使用了osFeature_MainThread==1宏，则就不用再显示调用osKernelStart()了，否则还需要调用并启动调度器。
说明：
1.RTX是开源的，只是你选用的是.lib，你可以选择使用RTX源文件并重新编译即可。
2.RTX又是特殊的，在Keil中的选项（Target）中可以显示指出。当然可以通过修改一些文件使keil支持其它RTOS。
3.为了保持兼容性，把main作为任务函数的优点并不明显。尽管在CMSIS-RTOS API框架下。
下面的也有关于main作为任务函数的CMSIS的说明：
http://www.keil.com/pack/doc/cms ... ___kernel_ctrl.html
不错，高见！灰常感谢！
楼主跑的是系统，如果有系统，main是可以结束的。在main里面创建了其他任务，虽然main结束了。但是其他的任务还是在运行。