为什么不对getqueucompletionstatus函数加锁? 而是对wsasend,wasrecv加锁？

[combobox2013]

为什么不对getqueucompletionstatus函数加锁? 而是对wsasend,wasrecv加锁？


背景：2个工作线程负责接受数据并投递接受请求。叫A，B线程。只有2个客户端。

分析：

A线程执行完一遍A的代码后，B的get函数才可能会返回，否则一直被堵塞。

跑完一遍A后， 此时有3种可能性，一种是A的get返回且接受数据，B堵塞，一种是B的get返回然后接受数据， 轮不到A。第三种：

A,B 两个线程都接受数据，可能时间稍有时差。但是2个线程都不堵塞。

也就说，不是某线程投递请求后，那么该线程就get返回接受数据，完全有可能是另一个线程get返回接受数据， 也有可能是

两个线程都接受数据同一个socket，也可能两个线程接受不同的socket。可以说情况较为复杂.



我们把数据压入到一个栈中，比如适配器std::stdack(栈), 从2个套接字对应的系统缓冲区里取出数据,压入同一个栈里，确实会乱。

乱的原因是：2个线程读取同一个缓冲区里的内容。这里的乱不是指" 顺序乱 "，顺序依然需要靠代码来进行排序。



看了一些老帖子， 大家都提到： 加锁的目的是防止对同一个套接字wsarecv, 我不明白，对wsarecv加锁后，难道就可以防止

多线程操作同一个套接字对应的的系统缓冲区了吗？ 读取缓冲区的函数是getcompletionstatus, 发送数据也是它， wsarecv，wsasend并不是真正的接受，发送数据，所作的工作，

这2个函数所作的工作仅仅是 投递请求。 getcompletionstatus函数查询状态后，会获取缓冲区里的内容的，

（内容有3种:已接受的数据，要发送的数据， 新的连接请求） ，要加锁，也自然是对get函数加锁.

[combobox2013]