在两个插座之间共享信息

Question

我试图实现一个基于UDP的服务器，它维护两个插座，一个用于控制（ctrl_sock），另一个用于数据传输（data_sock）。事情是，ctrl_sock总是上行链路，data_sock是下行链路。也就是说，客户端将通过ctrl_sock请求数据传输/停止，数据将通过data_sock发送给他们。

现在的问题是，由于模型没有连接，服务器将不得不维护已注册客户信息的列表（我称之为peers_context），以便它可以“盲目地”向他们推送数据，直到他们询问停止。在此盲传期间，客户端可能会异步通过ctrl_sock向服务器发送控制消息。除了初始请求和停止之外，这些信息也可以是例如文件部分的偏好。因此，peers_context必须异步更新。然而，通过data_sock的传输依赖于这个peers_context结构，因此引起了ctrl_sock和data_sock之间的同步问题。我的问题是，我能做些什么来安全地维护这两个袜子和peers_context结构，这样异步更新peers_context不会造成严重破坏。顺便说一下，peers_context的更新不会很频繁，这就是为什么我需要避免请求 - 回复模型。

我最初考虑的实现是在主线程（listener线程）中维护ctrl_sock，并且在另一个线程（工作线程）中维护通过data_sock进行的传输。但是，我发现在这种情况下很难同步。例如，如果我在peers_context中使用互斥锁，每当工作线程锁定peers_context时，由于工作线程无休止地工作，侦听线程在它需要修改peers_context时不再有权访问它。另一方面，如果侦听器线程持有peers_context并写入它，工作线程将无法读取peers_context并终止。有人可以给我一些建议吗？

顺便说一下，这个实现是在C语言的Linux环境下完成的。只有监听线程偶尔需要修改peers_context，工作线程只需要读取。衷心感谢！

Answer 1

如果您的peers_context存在强烈争用，那么您需要缩短关键部分。你谈到了使用互斥锁。我假设你已经考虑改变为读者+作家锁，并拒绝它，因为你不想让不断读者饿死作家。这个怎么样？

做一个非常小的结构，是一个间接引用peers_context这样的：

struct peers_context_handle { 
    pthread_mutex_t ref_lock; 
    struct peers_context *the_actual_context; 
    pthread_mutex_t write_lock; 
}; 

数据包的发送者（读者）和控制要求处理器（作家）总是通过这种间接访问peers_mutex。

假设：数据包发送者从不修改peers_context，也没有释放它。

帕克发件人简要锁手柄，获得peers_context的当前版本和解锁：

pthread_mutex_lock(&(handle->ref_lock)); 
peers_context = handle->the_actual_context; 
pthread_mutex_unlock(&(handle->ref_lock)); 

（在实践中，你甚至可以用锁做的路程，如果你介绍记忆障碍，因为指针解引用是对Linux支持的所有平台的原子，但我不会推荐它，因为你将不得不开始钻研记忆障碍和其他低层次的东西，也不ç也不POSIX保证它无论如何都会正常工作。）

请求处理器不更新peers_context，他们复制并共享完全取代它。这就是他们如何保持他们的关键部分小。他们做使用write_lock序列化更新，但更新很少，所以这不是问题。

pthread_mutex_lock(&(handle->write_lock)); 

/* Short CS to get the old version */ 
pthread_mutex_lock(&(handle->ref_lock)); 
old_peers_context = handle->the_actual_context; 
pthread_mutex_unlock(&(handle->ref_lock)); 

new_peers_context = allocate_new_structure(); 
*new_peers_context = *old_peers_context; 

/* Now make the changes that are requested */ 
new_peers_context->foo = 42; 
new_peers_context->bar = 52; 

/* Short CS to replace the context */ 
pthread_mutex_lock(&(handle->ref_lock)); 
handle->the_actual_context = new_peers_context; 
pthread_mutex_unlock(&(handle->ref_lock)); 

pthread_mutex_unlock(&(handle->write_lock)); 

magic(old_peers_context); 

这有什么用？这是最后一行代码中的魔力。您必须释放peers_context的旧副本以避免内存泄漏，但您无法这样做，因为可能有数据包发件人仍在使用该副本。

该解决方案与在Linux内核中使用的RCU类似。你必须等待所有的数据包发送者线程进入静态状态。我要离开这个实施作为练习你:-)但这里有准则：

• 的magic()函数添加old_peers_context所以要被释放队列（这必须由一个互斥体的保护）。
• 一个专用线程释放这个名单在一个循环：
  1. 它锁定到待释放名单
  2. 它获得的指针列表
  3. 它取代了清单，一个新的空单
  4. 它解锁，以待释放名单
  5. 它清除与每个工作线程
  6. 它等待所有标记再次设置
  7. 它释放每个相关的标记在其先前获得的待释放列表副本中的项目
• 同时，每个工作线程在其事件循环中的空闲点处设置其自己的标记（即，当它不忙于发送任何数据包或持有任何peer_contexts时。