接近实时处理系统的信号处理编程模式

现在有个需求：需要系统能用一个线程处理端口接收到的数据，并按需递交给需要的线程。

系统已有基础框架，可以存储各类数据。

初步想法：在系统框架上设置双指针，每次输入生成的对象交给外侧指针，处理需要的对象从内部指针获得；数据更新时，进行一个指针交换。数据更新频率约为50ms。

该模式在交换显存的前后页上被普遍使用。前后缓冲区就是用这种反转指针的方式，从而保证了显示异步刷新的正确。

但是，我们内部获取并生成记录的线程需要等待(200-5000ms)，会造成的后果就是，该处理尚未完成，指针已经被交换过无数次了,也不能保证其记录正确性和线程安全。

更换思维方式：外部获取的实时数据频率较高，但是不是每个数据都是需要的，交换指针不可行，那么我们就传递指针。

新处理方式：利用shared_ptr管理外部记录生存期，框架上只保留最后一次更新的shared_ptr，需要该数据的线程从框架上摘取一个shared_ptr作为私有变量，进行后续处理。

如此，便解决了同步问题，因为私有变量天生是线程安全的。哦活活活。

但是，问题出现了。因为外部接收线程每次都要new一个新的对象，导致效率降低得飞快，同时导致delete回收也频繁到吓人的程度——大量的内存操作影响到系统性能了。

解决方案一：使用内存池技术，因为可以预计到需要同时开工的线程数量，制作一个比其大一点点的内存池，就可以避免频繁的new / delete操作。

解决方案二：根据实际情况，外部线程每次只更新内部一个对象的数据。并在需要的时候，复制该对象并返回其地址，交给其它线程处理。

现在两种方案中，第二种需要线程同步复制机制，并伴随内存复制操作——该操作可能会导致实时性降低。第一种需要增加一个内存池在结构上，但是不会涉及内存复制操作，但是每次要去获取一个指针——虽然该操作是O(1)的。

好，目前偶这大脑能思考的就这么多，欢迎板砖，更欢迎玉石、玛瑙、水晶哈。