跨平台进程池背后的思想

    背景是基于业务需求，需要实现一个跨平台的项目。项目中由于有部分功能存在大量计算，所以打算单独分配一个进程去进行计算。
     进程池的实现与线程池的实现逻辑上如出一辙。但是实现上进程池的实现会比线程池实现复杂的多，主要比较复杂的点的就在于并发安全的任务队列。考虑到跨平台的要求，我使用的是boost库中用于进程管理的boost::process，具体使用请参阅相相关文档。
     目前是进程管理没有问题，下面就是需要考虑进程间的通信和并发控制的问题。进程间并发控制其实是比较好解决的，使用boost库中进程相关的有名锁、有名条件变量等即可，其都是基于全局共享内存，当然关于全局共享内存是如何在进程之间互相识别的这个问题，其实我们也能从其前缀得到一些启发：“有名”，那固然是你创建这些控制条件变量的时候取一个名字，很明显这个名字与全局共享内存块形成了一个映射，并且这个映射也是全局的，以便所有进程都能访问该变量。这一点你在程序中创建对应的对象并且使用的时候你就能深有体会。
     下面就是“最赖皮”的部分，任务队列的实现。我们都知道，关于池类技术都离不开一个生产者-消费者模型，可能是一对一也可能是多对多，横竖不管怎样，就是生产者将任务生产到一个队列，消费者基于这个队列进行消费。如果是在单进程多线程模型中这种队列十分好设计，因为维护队列的动态内存在我们程序中可控制的，可以依据任务的大小和数量进行分配。但是在多进程间，全局的共享内存只能进行固定的分配，没有动态分配的机制。所以使用全局共享变量去实现一个进程间并发安全的任务队列十分的麻烦并且可靠性会比较差。
     那我们能不能另辟蹊径呢？我们总结一下这个队列的特点：基于内存、进程共享、最好还要有访问阻塞的机制。redis的List“横空出世”！首先redis基于内存，进程共享redis-server，自然也就共享List，最让人欣喜的是该List具有阻塞机制，当List为空的时候，客户端访问该List的请求会被阻塞，这不就是刚好符合我们的需求吗？直接取代了条件变量的作用。你以为这就结束了？redis有分布式锁的机制，而我们的多进程的场景就符合分布式多节点多进程的场景，所以我们甚至能借助redis进行进程间的互斥和同步从而舍弃全局共享变量。当然redis的分布式锁别有一番讲究，推荐一篇关于redis分布式锁总结性的博客。
     最后的最后，其实我们就是把redis当做一个简易版的消息队列来使用了，redis还有订阅和发布的功能，妥妥的轻量版消息队列。