我们可以在 Sockets Map 上使用读写锁吗？答案

【问题标题】：Can we use read-write lock on Sockets Map?我们可以在 Sockets Map 上使用读写锁吗？
【发布时间】：2013-06-04 13:39:03
【问题描述】：

假设我们有 std::map 套接字映射，它是一个多线程应用程序。会有多个线程访问map中的socket发送socket数据，同时只有一个线程访问map中的socket接收数据，如果远端关闭，该线程也会删除SocketInfo*。

在上述情况下，我们可以使用读写锁（pthread_rwlock_t）来同步线程吗？如果是，我们是否比 pthread_mutex_t 有更多的好处？

史蒂夫

[伪代码]

     class CSocketIO {  
         std::map<int, SocketInfo*> m_Sockets; //socket value and socket info
         pthread_t  m_ReadingSocketThreads;   // for reading socket data
     };

     class CSession {
         void SendOutNetworkPackets(); //access sockets for sending sock data
         pthread_t m_WorkerThread;     // do jobs and send sock data
     };

     class CSomeClass {
         void SendOutNetworkPackets(); // also access sockets
         pthread_t m_WorkerThread;     // do jobs and send sock data
     };

【问题讨论】：

@Yvette 添加了一些伪代码

标签： c++ linux multithreading pthreads thread-synchronization

【解决方案1】：

是的，您可以使用读/写锁来执行此操作，实际上建议这样做。

好处是您可以同时拥有多个具有读/写锁的读取器，而如果您使用简单的互斥锁，如果一个线程正在读取，其他想要读取的线程会阻塞，从而有效地序列化读取。使用读/写锁，读取器只会在发生写入时阻塞。

【讨论】：

【解决方案2】：

您不允许两个线程同时写入同一个套接字，对吗？您只想保护对 SocketInfo* 的查找不受 map 的影响？

读写器锁很少有益，而且往往有害。当我的客户端在多线程程序中存在不确定性错误时，我寻找的第一个 罪魁祸首是不正确使用读写器锁。（您只能使用读卡器锁来保护真正为const 的函数调用。）

大概你的每个线程都在做这样的事情：

// do some work to figure out what to send
SocketInfo* my_socket_info = 0;

// critical section begins here
pthread_mutex_lock(the_map_mutex);
socket_map_t::const_iterator i = m_Sockets.find(id);
if (i != m_Sockets.end()) {
  my_socket_info = i->second;
}
pthread_mutex_unlock(the_map_mutex);
// critical section is done

if (my_socket_info != 0) {
  // do a bunch of work to actually send the data
  // (including acquiring a mutex specific to the socket unless
  // you have some other way of guaranteeing that the socket isn't
  // currently being written by some other thread)

您需要问的第二个问题（在“我真正保护的是const？”之后）是：the_map_mutex 锁定的时间百分比是多少？如果它低于 50% 左右，那么您就没有足够的争用来使读写器锁定获胜。通过测量单个线程在临界区中花费的时间百分比，然后乘以系统上的硬件线程数，您可以快速估算受 the_map_mutex 保护的临界区的利用率。

【讨论】：