在两个套接字之间共享信息

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 的更新不会很频繁，所以我需要避免使用请求-回复模式。

我对实现的初步考虑是，在主线程（监听线程）中维护 ctrl_sock，在另一个线程（工作线程）中维护data_sock 上的传输。但是，我发现在这种情况下很难同步。例如，如果我在peers_context 中使用互斥锁，那么每当工作线程锁定peers_context 时，当需要修改peers_context 时，侦听线程将无法再访问它，因为工作线程无休止地工作。另一方面，如果侦听器线程持有peers_context 并对其进行写入，则工作线程将无法读取peers_context 并终止。谁能给我一些建议？

顺便说一下，实现是在Linux环境下用C语言完成的。只有监听线程偶尔需要修改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，也永远不会释放它。

Packer 发送者短暂锁定手柄，获取peers_context 的当前版本并解锁：

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

（实际上，如果引入内存屏障，您甚至可以取消锁定，因为指针解引用在 Linux 支持的所有平台上都是原子的，但我不推荐它，因为您必须开始深入研究内存障碍和其他低级的东西，C 和 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 的时间点）设置自己的标记。