Accept() 是线程安全的吗？

Question

我目前正在用 C 语言为我正在做的课程编写一个简单的网络服务器。我们的一个要求是实现一个线程池来使用pthreads处理连接。

我知道我将如何粗略地执行此操作（在主线程中调用 accept 并将文件描述符传递给 freee 线程），但是我的朋友建议了一种替代方法，而不是我想到的方法：预先创建所有线程，并让它们在调用 accept 时永远循环。这个想法是，accept 将阻塞所有空闲线程，并且当连接进入时，仅将文件描述符提供给其中一个线程。然后，当给定线程完成连接后，它会循环返回并再次阻塞对 accept 的调用。本质上使用对accept()的调用作为信号量。他认为这将大大简化实现，因为您不需要跟踪哪些线程正忙，哪些线程已准备好连接。理论上它的延迟也会更低，因为线程可以立即开始执行（无需创建它）。

我的问题是，这安全吗？我打算实施它并尝试一下，但我还没有准备好，我很好奇想知道答案。我在 google 和 stackoverflow 上搜索过，但找不到任何人这样做。 accept 线程安全吗？我认为这种方法会产生更多的开销，因为您一直在运行所有线程，这两种方法只是简单的内存/延迟权衡吗？

编辑：我不确定这是否应该是社区维基，如果应该是，抱歉，我找不到按钮：P

Answer 1

是的。这是设计多线程服务器的常用方法和公认的设计实践。

您还可以多次fork并让子进程调用accept，这将允许您在不需要线程库的情况下进行多线程处理。较旧的服务器会这样做。

Answer 2

由于此内容已获得奖励，请求参考：

是的，accept() 是线程安全的，正如 POSIX 定义该术语一样。

相关参考文献为 POSIX.1 的第 2.9.1 节，当前版本表示：

本卷 POSIX.1-2017 定义的所有函数均应
线程安全，但以下函数不需要
线程安全。

[不包含 accept() 的列表]

为了完整起见，POSIX 确实定义了 accept()： https://pubs.opengroup.org/onlinepubs/9699919799/functions/accept.html，这样没有出现在异常列表中的 POSIX 函数，POSIX 指定它是线程安全的。

Answer 3

在评论中，@Rick（赏金提供者）说：

_{在某些方面我现在明白了。线程安全将是满足该行为的属性。我认为线程安全必须是同一进程中的线程。但现在我认为同一进程内的线程之间或不同进程之间的线程之间没有太大差异。在某些方面它们是相同的。所以线程安全的概念可以应用于这两种场景。}

关于线程安全的 POSIX 定义确实指的是同一进程中的线程（请参阅：§2.9）。

如果您询问 fork() 之后会发生什么，以及父级和子级同时调用 accept() 是否安全，我们首先注意到 POSIX 定义称为连接指示队列的系统资源。然后我们注意到 fork()< /a> 获取父级描述符的副本，因此子级和父级将访问相同的连接指示队列（就像文本文件的重复文件描述符将访问同一文件一样）。

此时，accept() 对每个进程（子进程和父进程）执行的操作的定义是相同的。

Answer 4

应用程序链接到系统上的 libc 实现，以便调用 accept() 和其他与套接字相关的函数（#include） ）。您想阅读其文档。

Linux 上最常见的 libc 实现来自 GNU（或者 Android 上的 Google bionic），它被称为 glibc，它非常有用。可能您正在（将）使用什么。如接受文档 对于 glibc：

函数：int Accept(int socket, struct sockaddr *addr, socklen_t *length_ptr)

初步：| MT-安全 | AS-安全 |交流安全 fd | 请参阅 POSIX 安全概念。

如中所述POSIX 安全概念，初步部分列举了以下属性：

根据 POSIX 标准中针对线程安全、异步信号安全和异步取消安全等安全上下文的标准进行评估。

下面是对这些概念的解释（另外，请检查维基百科上的“线程安全”以了解不同的方法实现线程安全）。根据文档，accept 被声明为 MT-Safe：

MT 安全或线程安全函数在存在其他线程的情况下可以安全地调用。 MT，在MT-Safe中，代表多线程。

MT 安全并不意味着函数是原子的，也不意味着它使用 POSIX 向用户公开的任何内存同步机制。甚至有可能按顺序调用 MT-Safe 函数不会产生 MT-Safe 组合。例如，让一个线程依次调用两个 MT 安全函数并不能保证相当于这两个函数组合的原子执行的行为，因为其他线程中的并发调用可能会以破坏性方式进行干扰。

跨库接口内联函数的整个程序优化可能会暴露不安全的重新排序，因此不建议跨 GNU C 库接口执行内联。在整个程序优化下，无法保证记录的 MT 安全状态。但是，用户可见标头中定义的函数被设计为可以安全内联。

事实上，glibc 的 accept 实现只是重定向到内核系统调用，这使得此描述对于 Linux 上的其他 libc 实现也很有用。系统（也可能只是执行到系统调用的重定向）。

---

另一方面，更通用的方法是检查 man-pages 项目<如果可用的话，您系统上的 /code>（在大多数系统上最接近官方文档），其中：

[...] 记录了用户空间程序使用的 Linux 内核和 C 库接口。对于 C 库，主要焦点是 GNU C 库 (glibc)，尽管在已知的情况下，还包括可用于 Linux 的其他 C 库的变体文档。

通过输入 man 2 Accept在命令行上：

[...]
符合

accept(): POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD (首先接受()
出现在 4.2BSD 中）。

我们看到 POSIX.1-2008是一个可行的参考（检查此相关描述Linux 系统的标准）。正如其他答案中已经说过的，POSIX.1 标准将 accept 函数指定为 (POSIX-)线程安全 (如基本定义，第 3.399 节线程安全中所定义），但未将其列在系统接口，第 2.9.1 节线程安全上。

---

最后，由于 glibc 只是委托内核的 accept()，因此最可靠的源代码是内核源代码（当然）。 这个答案在accept()ing时通过内核代码路径：看看并说服自己共享资源受自旋锁保护，特别是 套接字状态 和 等待应用程序接受的连接队列。