完成端口最重要的特性就是并发量。完成端口的并发量可以在创建该完成端口时指定。该并发量限制了与该完成端口相关联的可运行线程的数目。当与该完成端口相关联的可运行线程的总数目达到了该并发量,系统就会阻塞任何与该完成端口相关联的后续线程的执行,直到与该完成端口相关联的可运行线程数目下降到小于该并发量为止。最有效的假想是发生在有完成包在队列中等待,而没有等待被满足,因为此时完成端口达到了其并发量的极限。此时,一个正在运行中的线程调用GetQueuedCompletionStatus时,它就会立刻从队列中取走该完成包。这样就不存在着环境的切换,因为该处于运行中的线程就会连续不断地从队列中取走完成包,而其他的线程就不能运行了请问“此时,一个正在运行中的线程调用GetQueuedCompletionStatus时,它就会立刻从队列中取走该完成包。这样就不存在着环境的切换??”
这句话对否,其中不存在环境切换!

解决方案 »

  1.   

    环境切换只在线程切换时发生,微软推荐的执行线程为CPU的数量,所以创建该完成端口时合适的并发量应该对性能没什么影响.
      

  2.   

    我看到的代码中推荐的是cpu*2个线程,并且是来自sdk的范例,个人认为环境的切换是必然的,异步的机制已可以保证效率了。况且作为os还要考虑其他进程对cpu时间的影响。
      

  3.   

    IOCP是L/F THREAD POOL,一般情况下不存在CONTEXT SWITCH
      

  4.   

    不存在,并发模式就存在Context Switch
      

  5.   

    个人认为只有切换线程且线程处于非阻塞状态才会发生环境切换,操作系统应该不会随意切换到一个阻塞线程的,而只是查看状态。所以在GetQueuedCompletionStatus不返回时不会切换线程的,只有消息到来才会切换到对应的工作线程,也正是如此操作系统才具有并发处理能力的。
    另外微软建议一个CPU对应一个工作线程,也正是为了避免频繁的切换线程。
      

  6.   

    Context Switch一定是存在的,关键是看其对性能的影响是否严格。1~2Threads Per CPU.