c - 多线程访问数据结构

Question

我正在使用 C、pthreads 和套接字在 Linux 中编写应用程序。

这将是客户端-服务器应用程序，服务器将有 N+2 个线程，其中 N - 事件客户端的数量，一个线程用于接受新连接并为客户端创建线程，最后一个线程将接受用户输入。

我将使用链表来保存一些与我的应用程序相关的数据，每个客户端都会在我的列表中关联一个节点。这些客户端线程将以一定间隔更新存储在其节点中的信息，可能是一秒，也可能是两分钟，它会动态变化。

现在问题来了，如果用户请求，存储在链表中的信息需要写到标准输出。当然在写作期间我应该获得互斥体。我担心整个列表的一个互斥锁会影响性能。

我正在考虑将互斥体与每个节点相关联，但它会使某些指定节点的删除变得复杂(首先，我需要确保“stdout writer”线程不会遍历列表，我还需要获取我的节点和前一个节点的互斥锁以更改指向下一个节点的指针等等 - 我需要一直遍历到前一个节点或者我需要制作双链表)。

所以我想知道涉及多个互斥锁的解决方案是否在更复杂的代码、条件以及所有这些锁定、等待和解锁的情况下更好。

Answer 1

你是对的，拥有每个节点的互斥锁会使代码更复杂。这是您必须决定其值(value)的权衡。您可以对整个列表使用一个锁，这可能会导致锁争用，但代码在很大程度上不受锁存在的影响，因此更容易编写，或者您可以使用更多的锁来减少争用的机会，导致更好的性能，但代码更难编写和正确。您甚至可以通过为每组节点设置一个锁来在中间放置一些东西 - 将几个节点分配在一起并为该组设置一个锁 - 但是这样您就会遇到跟踪空闲列表和碎片化可能性的问题。

您需要考虑添加操作、删除操作和完整列表迭代以及其他操作(重组、搜索以及您的应用程序需要的任何其他操作)的相对频率。如果添加/删除非常频繁，但列表是每三个蓝色月亮一次，那么单锁可能很合适。但是，如果遍历列表(无论是为了完整转储数据，还是为了搜索或其他目的)非常普遍，那么更细粒度的方法就变得更有吸引力。您甚至可能需要考虑读取器/写入器锁而不是互斥体。