砂浆发货调度工作总结,熊掌

鱼还是熊掌：浅谈多进程多线程的选择关于多进程和多线程，教科书上最经典的一句话是 进程是资源分配的最小单位，线程是CPU调度的最小单位 ，这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那没有这么简单了，选的不好，会让你深受其害。

工作总结调度

经常在网络上看到有的XDJM问 多进程好还是多线程好？ 、 Linux下用多进程还是多线程？ 等等期望一劳永逸的问题，我只能说：没有，只有更好。

根据实际情况来判断，哪个更加合适是哪个好。 我们按照多个不同的维度，来看看多线程和多进程的对比（注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受）。 看起来比较简单，优势对比上是 线程 3.5 v 2.5 进程 ，我们只管选线程是了？呵呵，有这么简单我不用在这里浪费口舌了，还是那句话，没有的好与坏，只有哪个更加合适的问题。 1）需要频繁创建销毁的优先用线程原因请看上面的对比。

这种原则最常见的应用是Web服务器了，来一个连接建立一个线程，断了销毁线程，要是用进程，创建和销毁的代价是很难承受的2）需要进行大量计算的优先使用线程所谓大量计算，当然是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。 3）强相关的处理用线程，弱相关的处理用进程什么叫强相关、弱相关？理论上很难定义，给个简单的例子明白了。

一般的Server需要完成如下任务：消息收发、消息处理。 消息收发 和 消息处理 是弱相关的任务，而 消息处理 里面可能又分为 消息解码 、 业务处理 ，这两个任务相对来说相关性要强多了。 因此 消息收发 和 消息处理 可以分进程设计， 消息解码 、 业务处理 可以分线程设计。 当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。 4）可能要扩展到多机分布的用进程，多核分布的用线程原因请看上面对比。 5）都满足需求的情况下，用你最熟悉、最拿手的方式至于 数据共享、同步 、 编程、调试 、 可靠性 这几个维度的所谓的 复杂、简单 应该怎么取舍，我只能说：没有明确的选择方法。 但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。 需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是 进程+线程 的结合方式，千万不要真的陷入一种非此即彼的误区。 虽然我在后面的回复里面做了简单解释，但是感觉还是没有将彻底。 因为这里涉及到了一个CCR内一个很重要的知识点，也是CCR的组成部分之一：任务调度。 PS：这张可能会有些难懂，因为我本计划把CCR的任务处理策略放到后面来讲的，但是既然有人提到了这个问题，那我觉得顺其自然把这篇文提前贴出来应该是比较好的，大家若能把例子程序改变下策略选项，自己运行下，应该还是能够轻松搞懂的。 OK，那我们先看看 CCR是如何做任务调度 和 CCR提供的四种任务调度策略，然后再来看看为什么例子程序会出现 腊八粥 说的2个奇怪现象。 容器的类型（IPortElement）允许CCR在不知道元素类型的情况下将元素排队并将元素赋值给Task实例。 当上面的4步完成之后，生成的Task对象现在已经被调度逻辑分发(dealt)给了对应的DispatcherQueue。 【二】：一旦一个元素被放入DispatcherQueue，接下来将会做如下操作：step1. DispatcherQueue向它所属的Dispatcher发信号，告诉Dispatcher一个新的任务可以被执行了。 step2. Dispatcher通知一个或者多个TaskExecutionWorker类型对象。 每个TaskExecutionWorker对象管理一个操作系统线程。

调度工作

它将线程设置到一种高效的休眠状态，直到Dispatcher发出信号通知有元素可以被调度时。 step3. TaskExecutionWorker对象调用DispatcherQueue.Test方法从队列中获取一个任务。 如果是可用的任务，TaskExecutionWorker对象则调用ITask.Execute。 step4. Task.Execute方法调用关联在task对象上的delegate，并将一个或者多个关联在task上的参数传递进去。

总之：在CCR中，线程池处理的任务，是由DispatcherQueue产生的；而DispathcerQueue有是根据用户线程通过Port或PortSet提交给的数据 和 初始化时指定的委托来产生任务的。

这对于CPU处理速度低于消息产生速度的情况很有好处，该策略能够保证丢弃的最旧任务的同时的N个任务能都得到调度。 特别是在阻塞深度为1的时候，队列中保存的始终都是的任务。 2、ConstrainQueueDepthThrottleExecution 按照队列深度阻塞任务产生 适用于：消息不是规律产生，而是随机、爆炸性到达的情况。 这对于来自网络获知其他机器的消息很相似，该策略保证任务不会被丢失，通过阻塞消息Post到Port/PortSet的方法来降低任务产生的速度。 3、ConstrainSchedulingRateDiscardTasks 按照固定速度处理消息且丢失未处理的最旧消息 适用于：处理产生速度有规律的消息，比如播放视频。 在这种情况下一般所有的消息已经不是最重要的了，但保存的消息却很有意义，该策略能够保证代码会以固定的速度执行，即使消息以爆炸式的速度产生也没关系。

4、ConstrainSchedulingRateThrottleExecution 按照固定速度处理消息且阻塞任务缠上 适用于：消息产生源是同一处理器中的另一线程时。

工作总结

该策略会让消息的产生源慢下来，适应消息的处理速度，保证不会有任务丢失。

四、问题 解答问题例子程序在运行的时候出现：数据会乱序 和 数据丢失的现象。