1895_分离进程的能力

全部学习汇总： g_unix: UNIX系统学习笔记 (gitee.com)

有些理念可能在控制类的嵌入式系统中不好实施，尤其是没有unix这样的系统搭载的情况下。如果是考虑在RTOS的基础上看是否有一些理念可以做尝试，我觉得还是可以有一定的参考意义的。如果是让处理相互独立，设计上其实可以考虑为不同的task。但是，这样不同的task之间可能就会涉及到数据的传递。就我们现在看到的比较流行的开源RTOS来说，FreeRTOS中的队列等功能应该就是这样功能的一个很好模型。

对于前面我想到的嵌入式实时系统FreeRTOS中的可用模型来说，协议的传递机制其实是已经存在了的。如果考虑进一步的设计，那可能是传递协议中承载的数据格式。

我看到过有的RTOS也是支持管道机制的，如果按照这种描述我觉得这个功能还是非常不错的一个功能。因为在信息处理上，有了一个并行处理的模型。这样的话，数据处理其实是有更加灵活的处理方式，可能在大的数据组包等处理上会有更低延迟的可能性。

程序的分离涉及到的一个很重要的问题点就是分离后的各个模块之间的通信，前面考虑到了管道、信号等不同的形式，但是有一个很大的短板：信号的流向是单向的。如果要实现双向的信号流向功能，套接字是一个很好的选择。关于套接字，闻名已久，但是实际的用法还是不是很了解。可能在网络应用角度，这个会是一个很基础的应用。关于这个技术的基本的机制，后面可以了解一下以看看是否可以在我现在的一些工作中有借鉴的意义。至于我现在常用的RTOS以及控制类的嵌入式设计中，这种超级灵活的双向信息流转似乎的确是很少看到。

前面的很多技术考虑的方法都是协议或者机制，但是从实时性以及快速性的角度考虑，数据的共享以及交换通过一块可以多方一起访问的内存来实现也是一个方式。但是在这种多方操作的过程中，可能会有竞争以及同步等问题。这个是需要再软件层面做设计上的考虑。从资源开销上来说，共享内存会比套接字的方式有改善。

如果软件设计考虑分离设计的方式，那么就会带来数据共享以及传递的问题。继而，这样的设计可能会有锁定以及解锁以保证数据可靠的方式。如果是在性能要求敏感的设计中，这样的操作会比较低效。

类似的，这种处理的形式在嵌入式的程序中似乎也有这样的影子。如果是考虑有共享数据的存在，不同的任务甚至CPU之间的数据的同步在一致性上就得有独到的设计。否则，依赖于操作系统的同步机制，可能会带来很多响应上的延迟。

在unix的环境中做设计，如果考虑进行程序设计的分解，线程通常也不会是首选的方法。另外，线程解决的不是不同程序时间的通讯问题，而是单个程序的一个实例内的某种分时形式。