UDP并发服务器设计讨论：一台主机、一个CPU，实现单位时间内最大并发数

讨论：“一台主机、一个CPU”，用UDP实现单位时间内最大并发数的接入服务器的方案。设计方案不考虑特定OS系统。 
为了简化讨论，我们简化该服务器的流程：接收UDP包---->处理数据包。流程就两步，且假设接收 
UDP包的时间Tr和处理数据包的时间Tp的关系为：Tp = K*Tr。 
设计方案一：一个线程处理整个流程。 
设计方案二：一个接收线程+一个缓冲队列+一个处理线程。 
设计方案三：N个接收线程+一个缓冲队列+一个处理线程，其中N > 1。 
设计方案四：N个接收线程+N个缓冲队列+一个处理线程，其中N，M > 1，N和M可以相等。 
为更有利于讨论，我们再假设Tp = K*Tr中的K相当大，也就说，相对Tp,Tr可忽略不计（现实应用中大部分情况也是这样的^-^）。 
在K足够大的情况下，可以肯定，方案一并发性能是最差的。 
方案二实现起来最直观，要作数据写入队列和从队列读出数据时的同步，由于我们关心的写入性能，所以不用Multi Read Single Write锁进行同步。这里在要注意的是，从队列读出数据后就要解锁。 
方案三多了一些接收线程，但所有的接收线程和处理线程在写数据到缓冲队列列时都要作同步。 
方案四是一个接收线程对应一个缓冲队列，接收线程之间不须要同步（通过TSS)，但每一个接收线程还须要和处理线程同步。（有没有方法做到当两个读写线程同时访问公共资源的时候，不须要作同步？^-^）。 
我在这方面的经验不多，就两年前做过一个即时通信的接入服务器。当时做这个系统的时候，领导们催得紧，选择方案三，也经得起压力测试。 
但我现在想想，在一个CPU的情况下，方案二的性能比方案三的性能来得更高一些。方案四相对于方案二，可能可以支持更多的并发数，但性能会下降。为什么会得出这样的结论呢？因为方案四中的接收线程间不须要同步！可以肯定的是在多CPU的情况下，方案四是首选。 
我现在不从事这方面的工作了，没有那么多机器做测试，所以没有办法做这几个方案的比较测试，得出实验结果。希望兄弟们说出自己的观点；有条件的请给出测试数据。