paddle capi多线程调用不友善

[gujinji]

当前capi的paddle_gradient_machine非线程安全
每个线程都要维护自己的paddle_gradient_machine用于paddle_gradient_machine_forward
对于基于baidurpc等线上应用环境，如果需要不断更新模型数据的（比如ctr预估，每天都要更新模型）
会使得双buf更新模型数据特别复杂，需要更新多线程维护的paddle_gradient_machine，甚至，对于线程不固定的，会更加复杂
capi是否可以提供线程安全的forward方式

[shijiaxin]

能不能在其他机器上先把更新完的服务起起来，再让client去连接新的服务？

[hedaoyuan]

先确认一下，现在的用法是：一个server，多个线程，每个线程创建一个gradient machine，需要更新模型时，在线更新一遍每个线程对应的模型，这样？

[typhoonzero]

每个线程创建一个gradient machine并各自加载参数感觉还是挺占用内存的，考虑capi，load完参数之后，利用Linux的fork()，创建多个进程infer共享参数，只要每个进程写的内存相对参数小很多，就可以节省很多内存，每个进程变化的内存，应该只有，临时变量，layer的输出，LSTM memory，这些内存的大小对一个模型来说应该是相对固定的，变化的内存的部分可以交给Linux自己给每个子进程分配单独内存即可。

用这样的方式就可以实现inference worker process pool，只需要实现父进程(master process)可以控制这些子进程逐个替换模型，可以实现需要的功能。

参考：#4294