VxWorks 的 RTP 与内核任务：隔离性该怎么选？

VxWorks 6.x 之后引入了 RTP（Real-Time Process，实时进程），这是它从"所有代码跑在一个地址空间"向"进程隔离"迈出的关键一步。理解 RTP 和传统内核任务（kernel task）的区别，是 VxWorks 架构选型的第一课。

传统 VxWorks 任务跑在内核态、共享同一个地址空间。好处是高效：任务间通信就是直接读写共享内存，消息队列、信号量都是轻量实现，没有用户态/内核态切换的开销。坏处是脆弱：任何一个任务的野指针都可能踩掉内核数据或别的任务的内存，一次越界写就能让整个系统崩溃，而且崩了之后连现场都难查——因为内存已经被污染了。

RTP 把应用装进独立的用户态地址空间，每个 RTP 有自己的虚拟内存、自己的堆、自己的文件描述符表。一个 RTP 里跑的任务（还是 taskSpawn 那套 API，概念相通）只能访问自己的地址空间，野指针最多搞死自己这个进程，内核和其他 RTP 不受影响。代价是性能：RTP 任务做系统调用要陷入内核，RTP 之间的通信要走管道、消息队列或共享内存对象（需要显式创建），比内核态直接共享内存慢。但在现代 CPU 上，这点开销对大多数应用可接受。

什么场景该用 RTP？三类典型：第一，跑第三方/遗留代码，你信不过它的质量，RTP 相当于给它套了个沙箱；第二，高可靠性要求的系统，某个子系统崩了可以单独重启这个 RTP，不用整机复位；第三，多团队协作，每家负责一个 RTP，接口清晰，互相踩内存的扯皮直接消失。

什么场景坚持用内核任务？极致性能路径：中断服务程序、高速数据面、驱动，跑在内核态延迟最低。另外一些老代码迁移成本太高，重写 RTP 适配不划算，也可以留在内核态——但要做好代码审查。

RTP 和内核态的通信方式有讲究：RTP 不能直接调内核函数，要通过系统调用；RTP 之间推荐用消息队列（msgQ）和管道做控制面通信，大数据量用共享内存数据对象（sdOpen）但要自己做好同步。还有个细节：RTP 可以 spawn 内核任务吗？不行，RTP 里的任务只能是用户态任务；反过来内核可以管理 RTP（启动、停止、重启）。

调试习惯也要变：内核任务崩了用 windsh 看全局符号；RTP 崩了先看它的私有地址空间，core dump 是按 RTP 存的。建议开发阶段给每个 RTP 配独立的异常处理钩子，崩溃时把寄存器和调用栈记下来。

选型上我的经验是：新建项目默认 RTP，只有 profile 出来证明性能瓶颈在系统调用开销上，才把热点路径下沉到内核。大家在 VxWorks 项目里 RTP 用得多吗？有没有遇到过 RTP 间通信延迟超标的案例？

补充：RTP 之间可以通过共享数据区（sdCreate）、消息队列和 POSIX 机制通信，系统调用开销需要在性能敏感路径上评估；另外 RTP 支持在不重启系统的情况下加载、重启应用，对长时间运行的设备很有价值。你们项目里是把驱动放内核、业务放 RTP 吗？性能上有明显影响吗？