在前一篇中的流水作业系统中()，劳动者挂掉后，由项目经理来负责处理(重新分配该子任务)，这个影响相对比较小，但项目经理挂掉后，整个任务都要重新开始，就有点浪费了，这里我们采用土八路打仗的方式，让每个成员都知道打仗的目的和自己的任务（包括整体任务号，子任务号，项目经理是谁，自己负责处理的加工原料在那里，交互的产品放哪里等）同时这些成员在完成任务后，除了给项目经理报告结果之外，并不立即进行清场，而是要接到项目经理的指令后才清场，对于没有清场的任务，成员有义务每间隔一段时间发一个项目经理还活着没有的询问，如果多次询问，无结果的情况下，可以向Master报告，由Master暂时担当项目经理角色,这有4种情况：
1）项目经理没挂，而且任务已经结束，这种情况是由于发送清场指令出问题，则直接叫成员清场，并收归控制权;
2）项目经理没挂，但询问成员可能与项目经理不能直达(master可根据发过来的整体任务找到项目经理，如果项目经理匹配，且项目经理状态正常),这种情况下，Master就把信息转发给项目经理，直到成员可以直接跟项目经理通信为止；
3）项目经理挂掉，但还没有重新指定项目经理,这时master会记录这个成员的询问消息，并反馈成员一个稍安勿躁，等待新项目经理上任的的消息；
4）项目经理挂掉，且已经重新分配项目经理，则Master会把新的项目经理信息发给询问成员;
新任项目经理上任时，Master会将原来成员询问的消息一起给新的项目经理，项目经理开始任务时，会再次直接询问这些成员，并根据自己的任务计划来匹配某些任务是否要重新做。当然也可能由于成员汇报太迟，该子任务已经重新分配，那么项目经理接到成员消息后，可以根据策略逻辑是采纳这个结果或者放弃这个结果，如果是采纳，则通知在做这个任务的清场，而归队的成员则处于完成等待清场状态，如果选择放弃，则指示归队成员清场，并将控制交由master.
正常情况下，项目经理挂掉的情况还是比较少的，所以增加一点这种处理逻辑给master，不会是很大的负担。但相反，这种逻辑确实会增加一点劳动者的负担，但由于劳动者人数众多，每个劳动者增加一点维护询问是否要清场的逻辑，也不会对整体性能产生很大的影响。所以还是值得得。
当然，上述机制得以实现的一个前提是任务分配是可以重现的，是稳定的。对于大多时候这是可以做得到的(只要保证对加工原料的分配保持一个量和顺序上的稳定性)，比如对一个大文件进行处理，分配时对于文件块不进行分开分配，即一个文件块只分配给一个劳动者成员。