c++ - 线程间同一个socket的recv/send/close代码需要加锁吗

Question

来自类似 this 的帖子，我知道在 linux 上，recv/send 函数是线程安全的，允许用户同时从不同线程对同一个套接字进行操作。

虽然这不是一个好的设计，但在下面的情况下，我想知道我们应该从用户级代码做些什么来保持数据的一致性和健康的运行状态:有线程在同一个套接字上运行，第一个用于创建和关闭套接字，第二个用于读取套接字，最后一个用于发送套接字。看伪代码

 struct SocketInfo
 {
      int SockFd;
      int SockType;
      queue<Packet*> RecvPacks;
 };

 map<int, SocketInfo*> gSocketInfoMap;
 pthread_mutex_t       gSocketsLock;

 //Thread1
 pthread_mutex_lock(&gSocketsLock);
 // get information for sock
 SocketInfo* info = gSocketInfoMap[sock];
 pthread_mutex_unlock(&gSocketsLock);

 close(sock);         // line-1
 .....


 //thread-2
 pthread_mutex_lock(&gSocketsLock);
 SocketInfo* info = gSocketInfoMap[sock];
 pthread_mutex_unlock(&gSocketsLock);

 recv(sock, buffer, sizeof(buffer));         // line-2
 .....

 //thread-3
 pthread_mutex_lock(&gSocketsLock);
 SocketInfo* info = gSocketInfoMap[sock];
 pthread_mutex_unlock(&gSocketsLock);

 send(sock, buffer, sizeof buffer);         // line-3
 .....

请问是否需要将Line-1、Line-2、Line-3移入gSocketsLock的保护范围？为什么？

Answer 1

正如链接问题所述，套接字操作是线程安全的。在任何情况下，接收和发送数据都是独立的操作，互不干扰。

显然，关闭正在读写的套接字不是一个好主意，但是将 close() 放在关键部分并不能防止该错误.任何确保事件套接字不关闭或关闭的套接字不被访问的机制都比 OP 中显示的关键部分处于更高级别。

如果一个线程关闭另一个线程试图用于 I/O 的套接字，最坏的情况是 recv/send 调用将返回错误。

简而言之:不，将套接字操作放在临界区内不是一个好主意。它没有任何好处，而且不必要地增加了锁争用的可能性。