多线程 mprotect 的行为
Behavior of mprotect with multiple threads
为了 concurrent/parallel GC，
我感兴趣的是 mprotect 系统调用提供的内存顺序保证（即 mprotect 与多线程的行为或 mprotect 的内存模型）。我的问题是（假设没有编译器重新排序或有足够的编译器障碍）
如果线程 1 由于 mprotect on 而触发地址段错误
线程 2，我能确定一切都发生在线程 2 之前吗？
可以在线程 1 的信号处理程序中观察到系统调用
段错误？如果在信号中放置一个完整的内存屏障会怎样
在 thread1 上执行加载之前的处理程序？
如果线程 1 对设置为
PROT_NONE 由线程 2 触发并且没有触发段错误，这就足够了吗
a 发生在两者之间的关系之前。或者换句话说，如果
两个线程执行（*ga 以 0 开始，p 是页对齐地址以只读方式开始）
// thread 1
*ga = 1;
*(volatile int*)p; // no segfault happens
// thread 2
mprotect(p, 4096, PROT_NONE); // Or replace 4096 by the real userspace-visible page size
a = *ga;
是否可以保证线程 2 上的 a 将是 1？ （假设没有
在线程 1 上观察到段错误并且没有其他代码修改 *ga)
我最感兴趣的是 Linux 行为，尤其是 x86(_64)、arm/aarch64 和 ppc，但欢迎提供有关其他 archs/OS 的信息（对于 windows，将 mprotect 替换为 VirtualProtect 或任何它所称的....）。到目前为止，我在 x64 和 aarch64 上的测试 Linux 表明没有违反这些，尽管我不确定我的测试是否具有决定性，或者该行为是否可以长期依赖。
一些搜索表明，mprotect 可能会在删除权限时对映射地址的所有线程发出 TLB shootdown，这可能会提供此处所述的保证（或者换句话说，提供此保证似乎是这种操作的目标）虽然我不清楚未来内核代码的优化是否会打破这个保证。
参考 LKML post 我一周前问过这个问题，但还没有回复...
编辑：澄清问题。我知道 tlb 击落应该提供我正在寻找的保证，但我想知道是否可以依赖这种行为。换句话说，内核发出此类请求的原因是什么，因为如果不是为了提供某种排序保证，则不需要它。
所以我在此处发帖一天后在机械同情小组中提出了这个问题，并得到了 Gil Tene 的答复。在他的允许下，这是我对他的回答的总结。完整的线程可用 here 以防有任何我没有包含的内容不清楚。
OS.
的整体行为
(as in "would be surprising for an OS to not meet):
A call to mprotect() is fully ordered with respect to loads and stores that happen before and after the call. This tends to be trivially achieved at the CPU and OS level because mprotect is a system call, which involves a trap, which in turn involves full ordering. [In strange no-ring-transition-implementations (e.g. in-kernel execution, etc.) the protect call would be presumably responsible for emulating this ordering assumption].
A call to mprotect will not return before the protection request semantically takes hold everywhere within the process. If the mprotect() call sets a protection that would cause a fault, any operation on any thread that happens after this mprotect() call is required to fault. Similarly, if the mprotect() call sets a protection that would prevent a fault, any operation on any thread that happens after this mprotect() call is required to NOT fault.
这实质上意味着其他线程对受影响页面的内存操作与调用mprotect的线程同步。更具体地说，可以预期原始问题中提到的两种情况都得到保证。即
如果观察到由于 mprotect 调用导致受影响页面中的一个线程加载错误，则此错误发生在 mprotect() 调用之后，因此在并且能够观察到所有内存操作之后发生在 mprotect 之前。
如果观察到受影响页面中一个线程上的加载没有错误地阻止 mprotect 调用，则加载发生在 mprotect 调用之前，并且 mprotect 调用和它之后的任何代码都在之后加载并将能够观察加载之前发生的任何内存操作。
也有人指出，传递性可能不起作用，即一个线程上的错误加载可能不会在另一个线程上的非错误加载之后。这可能（实际上）是由于 tlb 刷新的非原子性导致不同 threads/cpus 观察者在不同时间访问权限的变化。
为了 concurrent/parallel GC， 我感兴趣的是 mprotect 系统调用提供的内存顺序保证（即 mprotect 与多线程的行为或 mprotect 的内存模型）。我的问题是（假设没有编译器重新排序或有足够的编译器障碍）
如果线程 1 由于 mprotect on 而触发地址段错误 线程 2，我能确定一切都发生在线程 2 之前吗？ 可以在线程 1 的信号处理程序中观察到系统调用 段错误？如果在信号中放置一个完整的内存屏障会怎样 在 thread1 上执行加载之前的处理程序？
如果线程 1 对设置为 PROT_NONE 由线程 2 触发并且没有触发段错误，这就足够了吗 a 发生在两者之间的关系之前。或者换句话说，如果 两个线程执行（
*ga以0开始，p是页对齐地址以只读方式开始）// thread 1 *ga = 1; *(volatile int*)p; // no segfault happens // thread 2 mprotect(p, 4096, PROT_NONE); // Or replace 4096 by the real userspace-visible page size a = *ga;是否可以保证线程 2 上的
a将是1？ （假设没有 在线程 1 上观察到段错误并且没有其他代码修改*ga)
我最感兴趣的是 Linux 行为，尤其是 x86(_64)、arm/aarch64 和 ppc，但欢迎提供有关其他 archs/OS 的信息（对于 windows，将 mprotect 替换为 VirtualProtect 或任何它所称的....）。到目前为止，我在 x64 和 aarch64 上的测试 Linux 表明没有违反这些，尽管我不确定我的测试是否具有决定性，或者该行为是否可以长期依赖。
一些搜索表明，mprotect 可能会在删除权限时对映射地址的所有线程发出 TLB shootdown，这可能会提供此处所述的保证（或者换句话说，提供此保证似乎是这种操作的目标）虽然我不清楚未来内核代码的优化是否会打破这个保证。
参考 LKML post 我一周前问过这个问题，但还没有回复...
编辑：澄清问题。我知道 tlb 击落应该提供我正在寻找的保证，但我想知道是否可以依赖这种行为。换句话说，内核发出此类请求的原因是什么，因为如果不是为了提供某种排序保证，则不需要它。
所以我在此处发帖一天后在机械同情小组中提出了这个问题，并得到了 Gil Tene 的答复。在他的允许下，这是我对他的回答的总结。完整的线程可用 here 以防有任何我没有包含的内容不清楚。
OS.
的整体行为(as in "would be surprising for an OS to not meet):
A call to mprotect() is fully ordered with respect to loads and stores that happen before and after the call. This tends to be trivially achieved at the CPU and OS level because mprotect is a system call, which involves a trap, which in turn involves full ordering. [In strange no-ring-transition-implementations (e.g. in-kernel execution, etc.) the protect call would be presumably responsible for emulating this ordering assumption].
A call to mprotect will not return before the protection request semantically takes hold everywhere within the process. If the mprotect() call sets a protection that would cause a fault, any operation on any thread that happens after this mprotect() call is required to fault. Similarly, if the mprotect() call sets a protection that would prevent a fault, any operation on any thread that happens after this mprotect() call is required to NOT fault.
这实质上意味着其他线程对受影响页面的内存操作与调用mprotect的线程同步。更具体地说，可以预期原始问题中提到的两种情况都得到保证。即
如果观察到由于 mprotect 调用导致受影响页面中的一个线程加载错误，则此错误发生在 mprotect() 调用之后，因此在并且能够观察到所有内存操作之后发生在 mprotect 之前。
如果观察到受影响页面中一个线程上的加载没有错误地阻止 mprotect 调用，则加载发生在 mprotect 调用之前，并且 mprotect 调用和它之后的任何代码都在之后加载并将能够观察加载之前发生的任何内存操作。
也有人指出，传递性可能不起作用，即一个线程上的错误加载可能不会在另一个线程上的非错误加载之后。这可能（实际上）是由于 tlb 刷新的非原子性导致不同 threads/cpus 观察者在不同时间访问权限的变化。