multithreading - 我可以安全地访问可能未分配的内存地址吗？

Question

我正在尝试创建类似memcpy的函数，当给内存中的地址是未分配页面的一部分时，该函数会优雅地失败(即，返回错误而不是segfaulting)。我认为正确的方法是安装sigsegv信号处理程序，并在处理程序中执行某些操作以使memcpy函数停止复制。

但是我不确定在我的程序是多线程的情况下会发生什么:

信号处理程序是否可以在另一个线程中执行？

如果段错误与任何memcpy操作无关，该怎么办？

如何处理两个同时执行memcpy的线程？

我还缺少其他东西吗？我是否在寻找无法实现的东西？

Answer 1

相信我，你不想走那条路。由于多种原因，这是一 jar 蠕虫。在单线程环境中，正确的信号处理已经很困难，而在多线程代码中则很难。

首先，由异常情况引起的信号处理程序返回的行为是不确定的-在Linux中有效，但仍然是不确定的行为，迟早会给您带来问题。

从man 2 sigaction:

The behaviour of a process is undefined after it returns normally from a signal-catching function for a SIGBUS, SIGFPE, SIGILL or SIGSEGV signal that was not generated by kill(), sigqueue() or raise().

(注意:这不会出现在Linux手册页上； but it's in SUSv2)

这也在POSIX中指定。尽管它可以在Linux中运行，但不是一个好习惯。

在您的问题的具体答案下方:

Is it possible for the signal handler to execute in another thread?

是的。尽管在Linux和许多其他UNIX变体中，通常将与异常相关的信号( SIGILL， SIGFPE， SIGBUS和 SIGSEGV)传递给一个信号，但该信号不会被阻塞(但仅传递给一个线程)。导致异常的线程。但是，这不是必需的，因此为了获得最大的可移植性，您不应依赖它。

您可以使用 pthread_sigmask(2)阻止每个线程中的信号，但一个线程除外。这样，您可以确保每个信号始终传递到同一线程。这样就可以轻松地拥有一个专用于信号处理的线程，这又使您可以执行同步信号处理，因为该线程可能会使用 sigwait(2)(请注意，多线程代码应使用 sigwait(2)而不是 sigsuspend(2))，直到传递信号为止，然后同步处理。这是非常常见的模式。

What happens if a segfault isn't related to any memcpy operation?

好问题。信号已传递，并且没有(简单的)方法可移植地将真正的段错误与 memcpy(3)中的段错误区分开。

如果您有一个线程负责处理每个信号，如我上面提到的，您可以使用 sigwaitinfo(2)，然后在 si_addr返回时检查 siginfo_t的 sigwaitinfo(2)字段。 si_addr字段是引起故障的内存位置，因此您可以将其与传递给 memcpy(3)的内存地址进行比较。

但是某些平台，尤其是Mac OS，并未实现 sigwaitinfo(2)或其表亲 sigtimedwait(2)。

因此，没有办法可移植地做到这一点。

How does one handle two threads executing memcpy concurrently?

我不太了解这个问题，多线程 memcpy(3)有什么特别之处？调用者有责任确保不会同时访问正在读取和写入的内存区域。如果您将 memcpy(3)传递给重叠缓冲区，则它不是(也从未如此)是线程安全的。

Am I missing something else? Am I looking for something that's impossible to implement?

如果您担心可移植性，我会说这几乎是不可能的。即使您只专注于Linux，也很难。如果这是一件容易的事，那么到那时这个人可能已经做到了。

我认为您最好构建自己的分配器，并强制用户代码依赖它。然后，您可以存储状态并管理分配的内存，并轻松判断所传递的缓冲区是否有效。