屏障之后的写入器如何在屏障之前的写入之前可见?

问题描述 投票:0回答:3
在Linux内核的内存屏障文档(Documentation/memory-barriers.txt)中,有一些示例表明,内存屏障之后的写入器在内存屏障之前的写入对其他CPU来说是可见的。怎么会发生这种事呢?为什么写屏障不足以排序这些写入?

特别是以下内容:

843 CPU 1 CPU 2 844 ======================= ======================= 845 { B = 7; X = 9; Y = 8; C = &Y } 846 STORE A = 1 847 STORE B = 2 848 <write barrier> 849 STORE C = &B LOAD X 850 STORE D = 4 LOAD C (gets &B) 851 LOAD *C (reads B) 852 853 Without intervention, CPU 2 may perceive the events on CPU 1 in some 854 effectively random order, despite the write barrier issued by CPU 1: 855 856 +-------+ : : : : 857 | | +------+ +-------+ | Sequence of update 858 | |------>| B=2 |----- --->| Y->8 | | of perception on 859 | | : +------+ \ +-------+ | CPU 2 860 | CPU 1 | : | A=1 | \ --->| C->&Y | V 861 | | +------+ | +-------+ 862 | | wwwwwwwwwwwwwwww | : : 863 | | +------+ | : : 864 | | : | C=&B |--- | : : +-------+ 865 | | : +------+ \ | +-------+ | | 866 | |------>| D=4 | ----------->| C->&B |------>| | 867 | | +------+ | +-------+ | | 868 +-------+ : : | : : | | 869 | : : | | 870 | : : | CPU 2 | 871 | +-------+ | | 872 Apparently incorrect ---> | | B->7 |------>| | 873 perception of B (!) | +-------+ | | 874 | : : | | 875 | +-------+ | | 876 The load of X holds ---> \ | X->9 |------>| | 877 up the maintenance \ +-------+ | | 878 of coherence of B ----->| B->2 | +-------+ 879 +-------+ 880 : : 881 882 883 In the above example, CPU 2 perceives that B is 7, despite the load of *C 884 (which would be B) coming after the LOAD of C.
    
linux-kernel shared-memory memory-model
3个回答
1
投票
写屏障

确实正确地排序写入。

正如下面的文字所解释的,问题是 CPU 2 可以在

*C

 之前读取 
C
,因为它不使用任何类型的读屏障。


0
投票
关于内存障碍的更好的文章是

http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf


0
投票
我认为这在 Alpha 上可能是可能的。看这篇文章:

https://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html

© www.soinside.com 2019 - 2024. All rights reserved.