summaryrefslogtreecommitdiffstats
path: root/Documentation/translations/sp_SP/memory-barriers.txt
blob: f62bd797216dd97a272e00de03a8f6452569aaea (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
NOTE:
This is a version of Documentation/memory-barriers.txt translated into
Spanish by Carlos Bilbao <carlos.bilbao@amd.com>. If you find any
difference between this document and the original file or a problem with
the translation, please contact the maintainer of this file. Please also
note that the purpose of this file is to be easier to read for non English
(read: Spanish) speakers and is not intended as a fork. So if you have any
comments or updates for this file please update the original English file
first. The English version is definitive, and readers should look there if
they have any doubt.

			 ======================================
			 BARRERAS DE MEMORIA EN EL KERNEL LINUX
			 ======================================

Documento original: David Howells <dhowells@redhat.com>
    Paul E. McKenney <paulmck@linux.ibm.com>
    Will Deacon <will.deacon@arm.com>
    Peter Zijlstra <peterz@infradead.org>

Traducido por: Carlos Bilbao <carlos.bilbao@amd.com>
Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
traducción, la única referencia válida es la documentación oficial en
inglés.

===========
ADVERTENCIA
===========

Este documento no es una especificación; es intencionalmente (por motivos
de brevedad) y sin querer (por ser humanos) incompleta. Este documento
pretende ser una guía para usar las diversas barreras de memoria
proporcionadas por Linux, pero ante cualquier duda (y hay muchas) por favor
pregunte. Algunas dudas pueden ser resueltas refiriéndose al modelo de
consistencia de memoria formal y documentación en tools/memory-model/. Sin
embargo, incluso este modelo debe ser visto como la opinión colectiva de
sus maintainers en lugar de que como un oráculo infalible.

De nuevo, este documento no es una especificación de lo que Linux espera
del hardware.

El propósito de este documento es doble:

 (1) especificar la funcionalidad mínima en la que se puede confiar para
     cualquier barrera en concreto, y

 (2) proporcionar una guía sobre cómo utilizar las barreras disponibles.

Tenga en cuenta que una arquitectura puede proporcionar más que el
requisito mínimo para cualquier barrera en particular, pero si la
arquitectura proporciona menos de eso, dicha arquitectura es incorrecta.

Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
para alguna arquitectura porque por la forma en que funcione dicha
arquitectura, la barrera explícita resulte innecesaria en ese caso.

==========
CONTENIDOS
==========

 (*) Modelo abstracto de acceso a memoria.

     - Operaciones del dispositivo.
     - Garantías.

 (*) ¿Qué son las barreras de memoria?

     - Variedades de barrera de memoria.
     - ¿Qué no se puede asumir sobre las barreras de memoria?
     - Barreras de dirección-dependencia (históricas).
     - Dependencias de control.
     - Emparejamiento de barreras smp.
     - Ejemplos de secuencias de barrera de memoria.
     - Barreras de memoria de lectura frente a especulación de carga.
     - Atomicidad multicopia.

 (*) Barreras explícitas del kernel.

     - Barrera del compilador.
     - Barreras de memoria de la CPU.

 (*) Barreras de memoria implícitas del kernel.

     - Funciones de adquisición de cerrojo.
     - Funciones de desactivación de interrupciones.
     - Funciones de dormir y despertar.
     - Funciones varias.

 (*) Efectos de barrera adquiriendo intra-CPU.

     - Adquisición vs accesos a memoria.

 (*) ¿Dónde se necesitan barreras de memoria?

     - Interacción entre procesadores.
     - Operaciones atómicas.
     - Acceso a dispositivos.
     - Interrupciones.

 (*) Efectos de barrera de E/S del kernel.

 (*) Modelo de orden mínimo de ejecución asumido.

 (*) Efectos de la memoria caché de la CPU.

     - Coherencia de caché.
     - Coherencia de caché frente a DMA.
     - Coherencia de caché frente a MMIO.

 (*) Cosas que hacen las CPU.

     - Y luego está el Alfa.
     - Guests de máquinas virtuales.

 (*) Ejemplos de usos.

     - Buffers circulares.

 (*) Referencias.


====================================
MODELO ABSTRACTO DE ACCESO A MEMORIA
====================================

Considere el siguiente modelo abstracto del sistema:

		            :                :
		            :                :
		            :                :
		+-------+   :   +--------+   :   +-------+
		|       |   :   |        |   :   |       |
		|       |   :   |        |   :   |       |
		| CPU 1 |<----->| Memoria|<----->| CPU 2 |
		|       |   :   |        |   :   |       |
		|       |   :   |        |   :   |       |
		+-------+   :   +--------+   :   +-------+
		    ^       :       ^        :       ^
		    |       :       |        :       |
		    |       :       |        :       |
		    |       :       v        :       |
		    |       :   +--------+   :       |
		    |       :   |        |   :       |
		    |       :   | Disposi|   :       |
		    +---------->| tivo   |<----------+
		            :   |        |   :
		            :   |        |   :
		            :   +--------+   :
		            :                :

Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria.
En la CPU abstracta, el orden de las operaciones de memoria es muy
relajado, y una CPU en realidad puede realizar las operaciones de memoria
en el orden que desee, siempre que la causalidad del programa parezca
mantenerse. De manera similar, el compilador también puede organizar las
instrucciones que emite en el orden que quiera, siempre que no afecte al
funcionamiento aparente del programa.

Entonces, en el diagrama anterior, los efectos de las operaciones de
memoria realizadas por un CPU son percibidos por el resto del sistema a
medida que las operaciones cruzan la interfaz entre la CPU y el resto del
sistema (las líneas discontinuas a puntos).

Por ejemplo, considere la siguiente secuencia de eventos:

	CPU 1		CPU 2
	===============	===============
	{ A == 1; B == 2 }
	A = 3;		x = B;
	B = 4;		y = A;

El conjunto de accesos visto por el sistema de memoria en el medio se puede
organizar en 24 combinaciones diferentes (donde LOAD es cargar y STORE es
guardar):

STORE A=3,	STORE B=4,	y=LOAD A->3,	x=LOAD B->4
STORE A=3,	STORE B=4,	x=LOAD B->4,	y=LOAD A->3
STORE A=3,	y=LOAD A->3,	STORE B=4,	x=LOAD B->4
STORE A=3,	y=LOAD A->3,	x=LOAD B->2,	STORE B=4
STORE A=3,	x=LOAD B->2,	STORE B=4,	y=LOAD A->3
STORE A=3,	x=LOAD B->2,	y=LOAD A->3,	STORE B=4
STORE B=4,	STORE A=3,	y=LOAD A->3,	x=LOAD B->4
STORE B=4, ...
...

y por lo tanto puede resultar en cuatro combinaciones diferentes de
valores:

x == 2, y == 1
x == 2, y == 3
x == 4, y == 1
x == 4, y == 3

Además, los stores asignados por una CPU al sistema de memoria pueden no
ser percibidos por los loads realizados por otra CPU en el mismo orden en
que fueron realizados.

Como otro ejemplo, considere esta secuencia de eventos:

	CPU 1		CPU 2
	===============	===============
	{ A == 1, B == 2, C == 3, P == &A, Q == &C }
	B = 4;		Q = P;
	P = &B;		D = *Q;

Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en
D depende en la dirección recuperada de P por la CPU 2. Al final de la
secuencia, cualquiera de los siguientes resultados son posibles:

  (Q == &A) y (D == 1)
  (Q == &B) y (D == 2)
  (Q == &B) y (D == 4)

Tenga en cuenta que la CPU 2 nunca intentará cargar C en D porque la CPU
cargará P en Q antes de emitir la carga de *Q.

OPERACIONES DEL DISPOSITIVO
---------------------------

Algunos dispositivos presentan sus interfaces de control como colecciones
de ubicaciones de memoria, pero el orden en que se accede a los registros
de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con
un conjunto de registros a los que se accede a través de un registro de
puerto de dirección (A) y un registro de datos del puerto (D). Para leer el
registro interno 5, el siguiente código podría entonces ser usado:

  *A = 5;
  x = *D;

pero esto podría aparecer como cualquiera de las siguientes dos secuencias:

  STORE *A = 5, x = LOAD *D
  x = LOAD *D, STORE *A = 5

el segundo de las cuales casi con certeza resultará en mal funcionamiento,
ya que se estableció la dirección _después_ de intentar leer el registro.


GARANTÍAS
---------

Hay algunas garantías mínimas que se pueden esperar de una CPU:

 (*) En cualquier CPU dada, los accesos a la memoria dependiente se
     emitirán en orden, con respeto a sí mismo. Esto significa que para:

	Q = READ_ONCE(P); D = READ_ONCE(*Q);

     donde READ_ONCE() es LEER_UNA_VEZ(), la CPU emitirá las siguientes
     operaciones de memoria:

	Q = LOAD P, D = LOAD *Q

     y siempre en ese orden. Sin embargo, en DEC Alpha, READ_ONCE() también
     emite una instrucción de barrera de memoria, de modo que una CPU DEC
     Alpha, sin embargo emite las siguientes operaciones de memoria:

	Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER

     Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador
     haga cosas inapropiadas.

 (*) Los loads y stores superpuestos dentro de una CPU en particular
     parecerán ser ordenados dentro de esa CPU. Esto significa que para:

	a = READ_ONCE(*X); WRITE_ONCE(*X, b);

     donde WRITE_ONCE() es ESCRIBIR_UNA_VEZ(), la CPU solo emitirá la
     siguiente secuencia de operaciones de memoria:

	a = LOAD *X, STORE *X = b

     Y para:

	WRITE_ONCE(*X, c); d = READ_ONCE(*X);

     la CPU solo emitirá:

	STORE *X = c, d = LOAD *X

  (Los loads y stores se superponen si están destinados a piezas
  superpuestas de memoria).

Y hay una serie de cosas que _deben_ o _no_ deben asumirse:

 (*) _No_debe_ asumirse que el compilador hará lo que usted quiera
     con referencias de memoria que no están protegidas por READ_ONCE() y
     WRITE ONCE(). Sin ellos, el compilador tiene derecho a hacer todo tipo
     de transformaciones "creativas", que se tratan en la sección BARRERA
     DEL COMPILADOR.

   (*) _No_debe_ suponerse que se emitirán loads y stores independientes
       en el orden dado. Esto significa que para:

	X = *A; Y = *B; *D = Z;

     podemos obtener cualquiera de las siguientes secuencias:

    X = LOAD *A,  Y = LOAD *B,  STORE *D = Z
   	X = LOAD *A,  STORE *D = Z, Y = LOAD *B
   	Y = LOAD *B,  X = LOAD *A,  STORE *D = Z
   	Y = LOAD *B,  STORE *D = Z, X = LOAD *A
   	STORE *D = Z, X = LOAD *A,  Y = LOAD *B
   	STORE *D = Z, Y = LOAD *B,  X = LOAD *A

 (*) Se _debe_ suponer que los accesos de memoria superpuestos pueden
     fusionarse o ser descartados. Esto significa que para:

	X = *A; Y = *(A + 4);

  podemos obtener cualquiera de las siguientes secuencias:

X = LOAD *A; Y = LOAD *(A + 4);
Y = LOAD *(A + 4); X = LOAD *A;
{X, Y} = LOAD {*A, *(A + 4) };

  Y para:

*A = X; *(A + 4) = Y;

  podemos obtener cualquiera de:

STORE *A = X; STORE *(A + 4) = Y;
STORE *(A + 4) = Y; STORE *A = X;
STORE {*A, *(A + 4) } = {X, Y};

Y hay anti-garantías:

(*) Estas garantías no se aplican a los campos de bits, porque los
    compiladores a menudo generan código para modificarlos usando
    secuencias de lectura-modificación-escritura no atómica. No intente
    utilizar campos de bits para sincronizar algoritmos paralelos.

(*) Incluso en los casos en que los campos de bits están protegidos por
    cerrojos (o "cerrojos", o "locks"), todos los componentes en un campo
    de bits dado deben estar protegidos por un candado. Si dos campos en un
    campo de bits dado están protegidos por diferentes locks, las
    secuencias de lectura-modificación-escritura no atómicas del lock
    pueden causar una actualización a una campo para corromper el valor de
    un campo adyacente.

(*) Estas garantías se aplican solo a escalares correctamente alineados y
    dimensionados. De "tamaño adecuado" significa actualmente variables que
    son del mismo tamaño que "char", "short", "int" y "long".
    "Adecuadamente alineado" significa la alineación natural, por lo tanto,
    no hay restricciones para "char", alineación de dos bytes para "short",
    alineación de cuatro bytes para "int", y alineación de cuatro u ocho
    bytes para "long", en sistemas de 32 y 64 bits, respectivamente. Tenga
    en cuenta que estos garantías se introdujeron en el estándar C11, así
    que tenga cuidado cuando utilice compiladores anteriores a C11 (por
    ejemplo, gcc 4.6). La parte de la norma que contiene esta garantía es
    la Sección 3.14, que define "ubicación de memoria" de la siguiente
    manera:

    ubicación de memoria
  ya sea un objeto de tipo escalar, o una secuencia máxima
  de campos de bits adyacentes, todos con ancho distinto de cero

  NOTE 1: Dos hilos de ejecución pueden actualizar y acceder
  ubicaciones de memoria separadas sin interferir entre
  ellos.

  NOTE 2: Un campo de bits y un miembro adyacente que no es un campo de
  bits están en ubicaciones de memoria separadas. Lo mismo sucede con
  dos campos de bits, si uno se declara dentro de un declaración de
  estructura anidada y el otro no, o si las dos están separados por una
  declaración de campo de bits de longitud cero, o si están separados por
  un miembro no declarado como campo de bits. No es seguro actualizar
  simultáneamente dos campos de bits en la misma estructura si entre
  todos los miembros declarados también hay campos de bits, sin importar
  cuál resulta ser el tamaño de estos campos de bits intermedios.


==================================
¿QUÉ SON LAS BARRERAS DE MEMORIA?
==================================

Como se puede leer arriba, las operaciones independientes de memoria se
realizan de manera efectiva en orden aleatorio, pero esto puede ser un
problema para la interacción CPU-CPU y para la E/S ("I/O"). Lo que se
requiere es alguna forma de intervenir para instruir al compilador y al
CPU para restringir el orden.

Las barreras de memoria son este tipo de intervenciones. Imponen una
percepción de orden parcial, sobre las operaciones de memoria a ambos lados
de la barrera.

Tal cumplimiento es importante porque las CPUs y otros dispositivos en un
sistema pueden usar una variedad de trucos para mejorar el rendimiento,
incluido el reordenamiento, diferimiento y combinación de operaciones de
memoria; cargas especulativas; predicción de "branches" especulativos y
varios tipos de almacenamiento en caché. Las barreras de memoria se
utilizan para anular o suprimir estos trucos, permitiendo que el código
controle sensatamente la interacción de múltiples CPU y/o dispositivos.


VARIEDADES DE BARRERA DE MEMORIA
---------------------------------

Las barreras de memoria vienen en cuatro variedades básicas:

 (1) Barreras de memoria al escribir o almacenar (Write or store memory
     barriers).

     Una barrera de memoria de escritura garantiza que todas las
     operaciones de STORE especificadas antes de que la barrera aparezca
     suceden antes de todas las operaciones STORE especificadas después
     de la barrera, con respecto a los otros componentes del sistema.

     Una barrera de escritura es un orden parcial solo en los stores; No
     es requerido que tenga ningún efecto sobre los loads.

     Se puede considerar que una CPU envía una secuencia de operaciones de
     store al sistema de memoria a medida que pasa el tiempo. Todos los
     stores _antes_ de una barrera de escritura ocurrirán _antes_ de todos
     los stores después de la barrera de escritura.

     [!] Tenga en cuenta que las barreras de escritura normalmente deben
     combinarse con read o barreras de address-dependency barriers
     (dependencia de dirección); consulte la subsección
     "Emparejamiento de barreras smp".


 (2) Barrera de dependencia de dirección (histórico).

     Una barrera de dependencia de dirección es una forma más débil de
     barrera de lectura. En el caso de que se realicen dos loads de manera
     que la segunda dependa del resultado de la primera (por ejemplo: el
     primer load recupera la dirección a la que se dirigirá el segundo
     load), una barrera de dependencia de dirección sería necesaria para
     asegurarse de que el objetivo de la segunda carga esté actualizado
     después de acceder a la dirección obtenida por la primera carga.

     Una barrera de dependencia de direcciones es una ordenación parcial en
     laods de direcciones interdependientes; no se requiere que tenga
     ningún efecto en los stores, ya sean cargas de memoria o cargas
     de memoria superpuestas.

     Como se mencionó en (1), las otras CPU en el sistema pueden verse como
     secuencias de stores en el sistema de memoria que la considerada CPU
     puede percibir. Una barrera de dependencia de dirección emitida por
     la CPU en cuestión garantiza que para cualquier carga que la preceda,
     si esa carga toca alguna secuencia de stores de otra CPU, entonces
     en el momento en que la barrera se complete, los efectos de todos los
     stores antes del cambio del load serán perceptibles por cualquier
     carga emitida después la barrera de la dependencia de la dirección.

     Consulte la subsección "Ejemplos de secuencias de barrera de memoria"
     para ver los diagramas mostrando las restricciones de orden.

     [!] Tenga en cuenta que la primera carga realmente tiene que tener una
     dependencia de _dirección_ y no es una dependencia de control. Si la
     dirección para la segunda carga depende de la primera carga, pero la
     dependencia es a través de un condicional en lugar de -en realidad-
     cargando la dirección en sí, entonces es una dependencia de _control_
     y se requiere una barrera de lectura completa o superior. Consulte la
     subsección "Dependencias de control" para más información.

     [!] Tenga en cuenta que las barreras de dependencia de dirección
     normalmente deben combinarse con barreras de escritura; consulte la
     subsección "Emparejamiento de barreras smp".

     [!] Desde el kernel v5.9, se eliminó la API del kernel para barreras
     de memoria de direcciones explícitas. Hoy en día, las APIs para marcar
     cargas de variables compartidas, como READ_ONCE() y rcu_dereference(),
     proporcionan barreras de dependencia de dirección implícitas.

 (3) Barreras de memoria al leer o cargar (Read or load memory
    barriers).

     Una barrera de lectura es una barrera de dependencia de direcciones,
     más una garantía de que todas las operaciones de LOAD especificadas
     antes de la barrera parecerán ocurrir antes de todas las operaciones
     de LOAD especificadas después de la barrera con respecto a los demás
     componentes del sistema.

     Una barrera de lectura es un orden parcial solo en cargas; no es
     necesario que tenga ningún efecto en los stores.

     Las barreras de memoria de lectura implican barreras de dependencia de
     direcciones, y por tanto puede sustituirlas por estas.

     [!] Tenga en mente que las barreras de lectura normalmente deben
     combinarse con barreras de escritura; consulte la subsección
     "Emparejamiento de barreras smp".

 (4) Barreras de memoria generales

     Una barrera de memoria general proporciona la garantía de que todas
     las operaciones LOAD y STORE especificadas antes de que la barrera
     aparezca suceden antes de que todas las operaciones LOAD y STORE
     especificadas después de la barrera con respecto a los demás
     componentes del sistema.

     Una barrera de memoria general es un orden parcial tanto en
     operaciones de carga como de almacenamiento.

     Las barreras de memoria generales implican barreras de memoria tanto
     de lectura como de escritura, de modo que pueden sustituir a
     cualquiera.

Y un par de variedades implícitas:

 (5)  ACQUIRE (de adquisición).

     Esto actúa como una barrera permeable unidireccional. Garantiza que
     toda las operaciones de memoria después de la operación ACQUIRE
     parezcan suceder después de la ACQUIRE con respecto a los demás
     componentes del sistema. Las operaciones ACQUIRE incluyen operaciones
     LOCK y smp_load_acquire(), y operaciones smp_cond_load_acquire().

     Las operaciones de memoria que ocurren antes de una operación ACQUIRE
     pueden parecer suceder después de que se complete.

     Una operación ACQUIRE casi siempre debe estar emparejada con una
     operación RELEASE (de liberación).


 (6) Operaciones RELEASE (de liberación).

     Esto también actúa como una barrera permeable unidireccional.
     Garantiza que todas las operaciones de memoria antes de la operación
     RELEASE parecerán ocurrir antes de la operación RELEASE con respecto a
     los demás componentes del sistema. Las operaciones de RELEASE incluyen
     operaciones de UNLOCK y operaciones smp_store_release().

     Las operaciones de memoria que ocurren después de una operación
     RELEASE pueden parecer suceder antes de que se complete.

     El uso de las operaciones ACQUIRE y RELEASE generalmente excluye la
     necesidad de otros tipos de barrera de memoria. Además, un par
     RELEASE+ACQUIRE NO garantiza actuar como una barrera de memoria
     completa. Sin embargo, después de un ACQUIRE de una variable dada,
     todos los accesos a la memoria que preceden a cualquier anterior
     RELEASE en esa misma variable están garantizados como visibles. En
     otras palabras, dentro de la sección crítica de una variable dada,
     todos los accesos de todas las secciones críticas anteriores para esa
     variable habrán terminado de forma garantizada.

     Esto significa que ACQUIRE actúa como una operación mínima de
     "adquisición" y RELEASE actúa como una operación mínima de
     "liberación".

Un subconjunto de las operaciones atómicas descritas en atomic_t.txt
contiene variantes de ACQUIRE y RELEASE, además de definiciones
completamente ordenadas o relajadas (sin barrera semántica). Para
composiciones atómicas que realizan tanto un load como store, la semántica
ACQUIRE se aplica solo a la carga y la semántica RELEASE se aplica sólo a
la parte de la operación del store.

Las barreras de memoria solo son necesarias cuando existe la posibilidad de
interacción entre dos CPU o entre una CPU y un dispositivo. Si se puede
garantizar que no habrá tal interacción en ninguna pieza de código en
particular, entonces las barreras de memoria son innecesarias en ese
fragmento de código.

Tenga en cuenta que estas son las garantías _mínimas_. Diferentes
arquitecturas pueden proporcionar garantías más sustanciales, pero no se
puede confiar en estas fuera de esa arquitectura en específico.


¿QUÉ NO SE PUEDE ASUMIR SOBRE LAS BARRERAS DE LA MEMORIA?
---------------------------------------------------------

Hay ciertas cosas que las barreras de memoria del kernel Linux no
garantizan:

 (*) No hay garantía de que ninguno de los accesos a la memoria
     especificados antes de una barrera de memoria estará _completo_ al
     completarse una instrucción de barrera de memoria; se puede considerar
     que la barrera dibuja una línea en la cola de acceso del CPU que no
     pueden cruzar los accesos del tipo correspondiente.

 (*) No hay garantía de que la emisión de una barrera de memoria en una CPU
     tenga cualquier efecto directo en otra CPU o cualquier otro hardware
     en el sistema. El efecto indirecto será el orden en que la segunda CPU
     ve los efectos de los primeros accesos que ocurren de la CPU, pero lea
     el siguiente argumento:

 (*) No hay garantía de que una CPU vea el orden correcto de los efectos
     de los accesos de una segunda CPU, incluso _si_ la segunda CPU usa una
     barrera de memoria, a menos que la primera CPU _también_ use una
     barrera de memoria coincidente (vea el subapartado "Emparejamiento de
     barrera SMP").

 (*) No hay garantía de que alguna pieza intermedia fuera del hardware[*]
     del CPU no reordenará los accesos a la memoria. Los mecanismos de
     coherencia de caché del CPU deben propagar los efectos indirectos de
     una barrera de memoria entre las CPU, pero es posible que no lo hagan
     en orden.

	[*] Para obtener información sobre bus mastering DMA y coherencia, lea:

	    Documentation/driver-api/pci/pci.rst
	    Documentation/core-api/dma-api-howto.rst
	    Documentation/core-api/dma-api.rst


BARRERA DE DEPENDENCIA DE DIRECCIÓN (HISTÓRICO)
-----------------------------------------------

A partir de la versión 4.15 del kernel Linux, se agregó un smp_mb() a
READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que
necesitan prestar atención a esta sección son aquellas que trabajan en el
código específico de la arquitectura DEC Alpha y aquellas que trabajan en
READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que
estén interesados ​​desde un punto de vista histórico, aquí está la historia
de las barreras de dependencia de dirección.

[!] Si bien las dependencias de direcciones se observan tanto en carga a
carga como en relaciones de carga a store, las barreras de dependencia de
dirección no son necesarias para situaciones de carga a store.

El requisito de las barreras de dependencia de dirección es un poco sutil,
y no siempre es obvio que sean necesarias. Para ilustrar, considere la
siguiente secuencia de eventos:

	CPU 1		      CPU 2
	===============	      ===============
	{ A == 1, B == 2, C == 3, P == &A, Q == &C }
	B = 4;
	<barrera de escritura>
	WRITE_ONCE(P, &B);
			      Q = READ_ONCE_OLD(P);
			      D = *Q;

[!] READ_ONCE_OLD() corresponde a READ_ONCE() del kernel anterior a 4.15,
que no implica una barrera de dependencia de direcciones.

Hay una clara dependencia de dirección aquí, y parecería que al final de
la secuencia, Q debe ser &A o &B, y que:

	(Q == &A) implica (D == 1)
	(Q == &B) implica (D == 4)

¡Pero! La percepción de la CPU 2 de P puede actualizarse _antes_ de su
percepción de B, por lo tanto dando lugar a la siguiente situación:

	(Q == &B) y (D == 2) ????

Si bien esto puede parecer una falla en el mantenimiento de la coherencia
o la causalidad, no lo es, y este comportamiento se puede observar en
ciertas CPU reales (como DEC Alfa).

Para lidiar con esto, READ_ONCE() proporciona una barrera de dependencia
de dirección implícita desde el lanzamiento del kernel v4.15:

	CPU 1		      CPU 2
	===============	      ===============
	{ A == 1, B == 2, C == 3, P == &A, Q == &C }
	B = 4;
	<barrera de escritura>
	WRITE_ONCE(P, &B);
			      Q = READ_ONCE(P);
			      <barrera de dependencia de dirección implícita>
			      D = *Q;

Esto refuerza la ocurrencia de una de las dos implicaciones, y previene la
tercera posibilidad de surgir.


[!] Tenga en cuenta que esta situación extremadamente contraria a la
intuición surge más fácilmente en máquinas con cachés divididos, de modo
que, por ejemplo, un banco de caché procesa líneas de caché pares y el otro
banco procesa líneas impares de caché. El puntero P podría almacenarse en
una línea de caché impar y la variable B podría almacenarse en una línea de
caché con número par. Entonces, si el banco de números pares de la memoria
caché de la CPU de lectura está extremadamente ocupado mientras que el
banco impar está inactivo, uno podría ver el nuevo valor del puntero P
(&B), pero el antiguo valor de la variable B (2).


No se requiere una barrera de dependencia de dirección para ordenar
escrituras dependientes porque las CPU que admite el kernel Linux no
escriben hasta que están seguros (1) de que la escritura realmente
sucederá, (2) de la ubicación de la escritura, y (3) del valor a escribir.
Pero, por favor, lea atentamente la sección "DEPENDENCIAS DEL CONTROL" y el
archivo Documentation/RCU/rcu_dereference.rst: el compilador puede romperse
y romper dependencias en muchas formas altamente creativas.

	CPU 1		      CPU 2
	===============	      ===============
	{ A == 1, B == 2, C = 3, P == &A, Q == &C }
	B = 4;
	<barrera de escritura>
	WRITE_ONCE(P, &B);
			      Q = READ_ONCE_OLD(P);
			      WRITE_ONCE(*Q, 5);

Por lo tanto, no se requiere ninguna barrera de dependencia de direcciones
para ordenar la lectura en Q con el load en *Q. En otras palabras, este
resultado está prohibido, incluso sin una barrera de dependencia de
dirección implícita del READ_ONCE() moderno:

	(Q == &B) && (B == 4)

Tenga en cuenta que este patrón debe ser raro. Después de todo, el objetivo
del orden de dependencia es -prevenir- escrituras en la estructura de
datos, junto con los costosos errores de caché asociados con tales
escrituras. Este patrón se puede utilizar para registrar raras condiciones
de error y similares, y el orden natural de las CPUs evita que se pierdan
tales registros.


Tenga en cuenta que el orden proporcionado por una dependencia de dirección
es local para la CPU que lo contiene. Lea la sección sobre "Atomicidad
multicopia" para más información.


La barrera de dependencia de dirección es muy importante para el sistema
RCU, por ejemplo. Vea rcu_assign_pointer() y rcu_dereference() en
include/linux/rcupdate.h. Esto permite que el objetivo actual de un puntero
RCU sea reemplazado con un nuevo objetivo modificado, sin que el objetivo
del reemplazo parezca estar inicializado de manera incompleta.

Consulte también la subsección sobre "Coherencia de caché" para obtener un
ejemplo más completo.

DEPENDENCIAS DE CONTROL
-----------------------

Las dependencias de control pueden ser un poco complicadas porque los
compiladores actuales no las entienden. El propósito de esta sección es
ayudarle a prevenir que la ignorancia del compilador rompa su código.

Una dependencia de control load-load (de carga a carga) requiere una
barrera de memoria de lectura completa, no simplemente una barrera
(implícita) de dependencia de direcciones para que funcione correctamente.
Considere el siguiente fragmento de código:

	q = READ_ONCE(a);
	<barrera implícita de dependencia de direcciones>
	if (q) {
		/* BUG: No hay dependencia de dirección!!! */
		p = READ_ONCE(b);
	}

Esto no tendrá el efecto deseado porque no hay una dependencia de dirección
real, sino más bien una dependencia de control que la CPU puede
cortocircuitar al intentar predecir el resultado por adelantado, para que
otras CPU vean la carga de b como si hubiera ocurrido antes que la carga de
a. En cuyo caso lo que realmente se requiere es:

  	q = READ_ONCE(a);
  	if (q) {
  		<barrera de lectura>
  		p = READ_ONCE(b);
  	}

Sin embargo, los stores no se especulan. Esto significa que ordenar -es-
provisto para dependencias de control de load-store, como en el siguiente
ejemplo:

	q = READ_ONCE(a);
	if (q) {
		WRITE_ONCE(b, 1);
	}

Las dependencias de control se emparejan normalmente con otros tipos de
barreras. Dicho esto, tenga en cuenta que ni READ_ONCE() ni WRITE_ONCE()
son opcionales! Sin READ_ONCE(), el compilador podría combinar la carga de
'a' con otras cargas de 'a'. Sin WRITE_ONCE(), el compilador podría
combinar el store de 'b' con otros stores de 'b'. Cualquiera de estos casos
puede dar lugar a efectos en el orden muy contrarios a la intuición.

Peor aún, si el compilador puede probar (decir) que el valor de la
variable 'a' siempre es distinta de cero, estaría dentro de sus derechos
para optimizar el ejemplo original eliminando la declaración "if", como:

	q = a;
	b = 1;  /* BUG: Compilador y CPU pueden ambos reordernar!!! */

Así que no deje de lado READ_ONCE().

Es tentador tratar de hacer cumplir el orden en stores idénticos en ambos
caminos del "if" de la siguiente manera:

	q = READ_ONCE(a);
	if (q) {
		barrier();
		WRITE_ONCE(b, 1);
		hacer_algo();
	} else {
		barrier();
		WRITE_ONCE(b, 1);
		hacer_otra_cosa();
	}

Desafortunadamente, los compiladores actuales transformarán esto de la
siguiente manera en casos de alto nivel de optimización:

  	q = READ_ONCE(a);
  	barrier();
  	WRITE_ONCE(b, 1);  /* BUG: No hay orden en load de a!!! */
  	if (q) {
  		/* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */
  		hacer_algo();
  	} else {
  		/* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */
  		hacer_otra_cosa();
  	}

Ahora no hay condicional entre la carga de 'a' y el store de 'b', lo que
significa que la CPU está en su derecho de reordenarlos: El condicional es
absolutamente necesario y debe estar presente en el código ensamblador
incluso después de que se hayan aplicado todas las optimizaciones del
compilador. Por lo tanto, si necesita ordenar en este ejemplo, necesita
explícitamente barreras de memoria, por ejemplo, smp_store_release():


	q = READ_ONCE(a);
	if (q) {
		smp_store_release(&b, 1);
		hacer_algo();
	} else {
		smp_store_release(&b, 1);
		hacer_otra_cosa();
	}

Por el contrario, sin barreras de memoria explícita, el control de un if
con dos opciones está garantizado solo cuando los stores difieren, por
ejemplo:

  	q = READ_ONCE(a);
  	if (q) {
  		WRITE_ONCE(b, 1);
  		hacer_algo();
  	} else {
  		WRITE_ONCE(b, 2);
  		hacer_otra_cosa();
  	}

Aún se requiere el inicial READ_ONCE() para evitar que el compilador toque
el valor de 'a'.

Además, debe tener cuidado con lo que hace con la variable local 'q', de lo
contrario, el compilador podría adivinar el valor y volver a eliminar el
necesario condicional. Por ejemplo:

  	q = READ_ONCE(a);
  	if (q % MAX) {
  		WRITE_ONCE(b, 1);
  		hacer_algo();
  	} else {
  		WRITE_ONCE(b, 2);
  		hacer_otra_cosa();
  	}

Si MAX se define como 1, entonces el compilador sabe que (q % MAX) es igual
a cero, en cuyo caso el compilador tiene derecho a transformar el código
anterior en el siguiente:

  	q = READ_ONCE(a);
  	WRITE_ONCE(b, 2);
  	hacer_otra_cosa();

Dada esta transformación, la CPU no está obligada a respetar el orden entre
la carga de la variable 'a' y el store de la variable 'b'. Es tentador
agregar una barrier(), pero esto no ayuda. El condicional se ha ido, y la
barrera no lo traerá de vuelta. Por lo tanto, si confia en este orden, debe
asegurarse de que MAX sea mayor que uno, tal vez de la siguiente manera:

  	q = READ_ONCE(a);
  	BUILD_BUG_ON(MAX <= 1); /* Orden de carga de a con store de b */
  	if (q % MAX) {
  		WRITE_ONCE(b, 1);
  		hacer_algo();
  	} else {
  		WRITE_ONCE(b, 2);
  		hacer_otra_cosa();
  	}

Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran
idénticos, como se señaló anteriormente, el compilador podría sacar ese
store fuera de la declaración 'if'.

También debe tener cuidado de no confiar demasiado en el cortocircuito
de la evaluación booleana. Considere este ejemplo:

  	q = READ_ONCE(a);
  	if (q || 1 > 0)
  	WRITE_ONCE(b, 1);

Debido a que la primera condición no puede fallar y la segunda condición es
siempre cierta, el compilador puede transformar este ejemplo de la
siguiente manera, rompiendo la dependencia del control:

  	q = READ_ONCE(a);
  	WRITE_ONCE(b, 1);

Este ejemplo subraya la necesidad de asegurarse de que el compilador no
pueda adivinar su código. Más generalmente, aunque READ_ONCE() fuerza
al compilador para emitir código para una carga dada, no fuerza al
compilador para usar los resultados.

Además, las dependencias de control se aplican solo a la cláusula then y
la cláusula else de la sentencia if en cuestión. En particular, no se
aplica necesariamente al código que sigue a la declaración if:

  	q = READ_ONCE(a);
  	if (q) {
  		WRITE_ONCE(b, 1);
  	} else {
  		WRITE_ONCE(b, 2);
  	}
  	WRITE_ONCE(c, 1);  /* BUG: No hay orden para la lectura de 'a'. */

Es tentador argumentar que, de hecho, existe un orden porque el compilador
no puede reordenar accesos volátiles y tampoco puede reordenar escrituras
en 'b' con la condición. Desafortunadamente para esta línea de
razonamiento, el compilador podría compilar las dos escrituras en 'b' como
instrucciones de movimiento condicional, como en este fantástico idioma
pseudo-ensamblador:

        	ld r1,a
        	cmp r1,$0
        	cmov,ne r4,$1
        	cmov,eq r4,$2
        	st r4,b
        	st $1,c

Una CPU débilmente ordenada no tendría dependencia de ningún tipo entre la
carga de 'a' y el store de 'c'. Las dependencias de control se extenderían
solo al par de instrucciones cmov y el store dependiente de ellas. En
resumen, las dependencias de control se aplican solo a los stores en la
cláusula then y la cláusula else de la sentencia if en cuestión (incluidas
las funciones invocado por esas dos cláusulas), no al código que sigue a
esa declaración if.


Tenga muy en cuenta que el orden proporcionado por una dependencia de
control es local a la CPU que lo contiene. Vea el apartado de "Atomicidad
multicopia" para más información.


En resumen:

  (*) Las dependencias de control pueden ordenar cargas anteriores para
      stores posteriores. Sin embargo, no garantizan ningún otro tipo de
      orden: No cargas previas contra cargas posteriores, ni
      almacenamientos previos y luego nada. Si necesita tales formas de
      orden, use smp_rmb(), smp_wmb() o, en el caso de stores anteriores y
      cargas posteriores, smp_mb().

  (*) Si ambos caminos de la declaración "if" comienzan con stores
      idénticos de la misma variable, entonces esos stores deben ser
      ordenados, ya sea precediéndoles a ambos con smp_mb() o usando
      smp_store_release() para realizar el store. Tenga en cuenta que -no-
      es suficiente usar barrier() al comienzo de cada caso de la
      declaración "if" porque, como se muestra en el ejemplo anterior, la
      optimización de los compiladores puede destruir la dependencia de
      control respetando al pie de la letra la ley de barrier().

  (*) Las dependencias de control requieren al menos un condicional en
      tiempo de ejecución entre la carga anterior y el almacenamiento
      posterior, y este condicional debe implicar la carga previa. Si el
      compilador es capaz de optimizar el condicional y quitarlo, también
      habrá optimizado el ordenar. El uso cuidadoso de READ_ONCE() y
      WRITE_ONCE() puede ayudar a preservar el necesario condicional.

  (*) Las dependencias de control requieren que el compilador evite
      reordenar las dependencia hasta su inexistencia. El uso cuidadoso de
      READ_ONCE() o atomic{,64}_read() puede ayudarle a preservar la
      dependencia de control. Consulte la sección BARRERA DEL COMPILADOR
      para obtener más información al respecto.

  (*) Las dependencias de control se aplican solo a la cláusula then y la
      cláusula else de la sentencia "if" que contiene la dependencia de
      control, incluyendo cualquier función a la que llamen dichas dos
      cláusulas. Las dependencias de control no se aplican al código que
      sigue a la instrucción if que contiene la dependencia de control.

  (*) Las dependencias de control se emparejan normalmente con otros tipos
      de barreras.

  (*) Las dependencias de control no proporcionan atomicidad multicopia. Si
      usted necesita todas las CPU para ver un store dado al mismo tiempo,
      emplee smp_mb().

  (*) Los compiladores no entienden las dependencias de control. Por lo
      tanto es su trabajo asegurarse de que no rompan su código.


EMPAREJAMIENTO DE BARRERAS SMP
------------------------------

Cuando se trata de interacciones CPU-CPU, ciertos tipos de barrera de
memoria deben estar siempre emparejados. La falta del apropiado
emparejamiento es casi seguro un error.

Las barreras generales se emparejan entre sí, aunque también se emparejan
con la mayoría de otro tipo de barreras, aunque sin atomicidad multicopia.
Una barrera de adquisición se empareja con una barrera de liberación, pero
ambas también pueden emparejarse con otras barreras, incluidas, por
supuesto, las barreras generales. Una barrera de escritura se empareja con
una barrera de dependencia de dirección, una dependencia de control, una
barrera de adquisición, una barrera de liberación, una barrera de lectura
o una barrera general. Del mismo modo, una barrera de lectura se empareja
con una de dependencia de control o barrera de dependencia de dirección con
una barrera de escritura, una barrera de adquisición, una barrera de
liberación o una barrera general:

	CPU 1		      CPU 2
	===============	      ===============
	WRITE_ONCE(a, 1);
	<barrera de escritura>
	WRITE_ONCE(b, 2);     x = READ_ONCE(b);
			      <barrera de lectura>
			      y = READ_ONCE(a);

O bien:

	CPU 1		      CPU 2
	===============	      ===============================
	a = 1;
	<barrera de escritura>
	WRITE_ONCE(b, &a);    x = READ_ONCE(b);
			      <barrera de dependencia de dirección implícita>
			      y = *x;

O incluso:

	CPU 1		      CPU 2
	===============	      ===============================
	r1 = READ_ONCE(y);
	<barrera general>
	WRITE_ONCE(x, 1);     if (r2 = READ_ONCE(x)) {
			         <barrera de control implícita>
			         WRITE_ONCE(y, 1);
			      }

	assert(r1 == 0 || r2 == 0);

Básicamente, la barrera de lectura siempre tiene que estar ahí, aunque
puede ser del tipo "más débil".

[!] Tenga en cuenta que normalmente se esperaría que los stores antes de la
barrera de escritura se hagan coincidir con los stores después de la
barrera de lectura o la barrera de dependencia de dirección, y viceversa:

	CPU 1                               CPU 2
	===================                 ===================
	WRITE_ONCE(a, 1);    }----   --->{  v = READ_ONCE(c);
	WRITE_ONCE(b, 2);    }    \ /    {  w = READ_ONCE(d);
	<barrera de escritura>            \        <barrera de lectura>
	WRITE_ONCE(c, 3);    }    / \    {  x = READ_ONCE(a);
	WRITE_ONCE(d, 4);    }----   --->{  y = READ_ONCE(b);


EJEMPLOS DE SECUENCIAS DE BARRERA DE MEMORIA
--------------------------------------------

En primer lugar, las barreras de escritura actúan como orden parcial en las
operaciones de store. Considere la siguiente secuencia de eventos:

	CPU 1
	=======================
	STORE A = 1
	STORE B = 2
	STORE C = 3
	<barrera de escritura>
	STORE D = 4
	STORE E = 5

Esta secuencia de eventos es finalizado para con el sistema de coherencia
de memoria en un orden que el resto del sistema podría percibir como el
conjunto desordenado { STORE A, STORE B, STORE C} todo ocurriendo antes del
conjunto desordenado { STORE D, STORE E}:


	+-------+       :      :
	|       |       +------+
	|       |------>| C=3  |     }     /\
	|       |  :    +------+     }-----  \  -----> Eventos perceptibles para
	|       |  :    | A=1  |     }        \/       el resto del sistema
	|       |  :    +------+     }
	| CPU 1 |  :    | B=2  |     }
	|       |       +------+     }
	|       |   wwwwwwwwwwwwwwww }   <--- En este momento la barrera de
	|       |       +------+     }        escritura requiere que todos los
	|       |  :    | E=5  |     }        stores anteriores a la barrera
	|       |  :    +------+     }        sean confirmados antes de que otros
	|       |------>| D=4  |     }        store puedan suceder
	|       |       +------+
	+-------+       :      :
	                   |
	                   | Secuencia por la cual los stores son confirmados al
	                   | sistema de memoria por parte del CPU 1
	                   V

En segundo lugar, las barreras de dependencia de dirección actúan como
órdenes parciales sobre la dirección de cargas dependientes. Considere la
siguiente secuencia de eventos:

	CPU 1			CPU 2
	=======================	=======================
		{ B = 7; X = 9; Y = 8; C = &Y }
	STORE A = 1
	STORE B = 2
	<barrera de escritura>
	STORE C = &B		LOAD X
	STORE D = 4		LOAD C (consigue &B)
				LOAD *C (lee B)

Sin intervención, la CPU 2 puede percibir los eventos en la CPU 1 en orden
aleatorio a efectos prácticos, a pesar de la barrera de escritura emitida
por la CPU 1:

	+-------+       :      :                :       :
	|       |       +------+                +-------+  | Secuencia de
	|       |------>| B=2  |-----       --->| Y->8  |  | actualizado de
	|       |  :    +------+     \          +-------+  | percepción en CPU 2
	| CPU 1 |  :    | A=1  |      \     --->| C->&Y |  V
	|       |       +------+       |        +-------+
	|       |   wwwwwwwwwwwwwwww   |        :       :
	|       |       +------+       |        :       :
	|       |  :    | C=&B |---    |        :       :       +-------+
	|       |  :    +------+   \   |        +-------+       |       |
	|       |------>| D=4  |    ----------->| C->&B |------>|       |
	|       |       +------+       |        +-------+       |       |
	+-------+       :      :       |        :       :       |       |
	                               |        :       :       |       |
	                               |        :       :       | CPU 2 |
	                               |        +-------+       |       |
	    Percepción de B      --->  |        | B->7  |------>|       |
	    aparentemente incorrecta!  |        +-------+       |       |
	                               |        :       :       |       |
	                               |        +-------+       |       |
	    La carga de X frena --->    \       | X->9  |------>|       |
	    el mantenimiento de          \      +-------+       |       |
	    la coherencia de B            ----->| B->2  |       +-------+
	                                        +-------+
	                                        :       :


En el ejemplo anterior, la CPU 2 percibe que B es 7, a pesar de la carga de
*C (que sería B) viniendo después del LOAD de C.

Sin embargo, si se colocara una barrera de dependencia de dirección entre
la carga de C y la carga de *C (es decir: B) en la CPU 2:

	CPU 1			CPU 2
	=======================	=======================
		{ B = 7; X = 9; Y = 8; C = &Y }
	STORE A = 1
	STORE B = 2
	<barrera de escritura>
	STORE C = &B		LOAD X
	STORE D = 4		LOAD C (consigue &B)
				<barrera de dependencia de dirección>
				LOAD *C (reads B)

entonces ocurrirá lo siguiente:

	+-------+       :      :                :       :
	|       |       +------+                +-------+
	|       |------>| B=2  |-----       --->| Y->8  |
	|       |  :    +------+     \          +-------+
	| CPU 1 |  :    | A=1  |      \     --->| C->&Y |
	|       |       +------+       |        +-------+
	|       |   wwwwwwwwwwwwwwww   |        :       :
	|       |       +------+       |        :       :
	|       |  :    | C=&B |---    |        :       :       +-------+
	|       |  :    +------+   \   |        +-------+       |       |
	|       |------>| D=4  |    ----------->| C->&B |------>|       |
	|       |       +------+       |        +-------+       |       |
	+-------+       :      :       |        :       :       |       |
	                               |        :       :       |       |
	                               |        :       :       | CPU 2 |
	                               |        +-------+       |       |
	                               |        | X->9  |------>|       |
	                               |        +-------+       |       |
	  Se asegura de que      --->   \   aaaaaaaaaaaaaaaaa   |       |
	  los efectos anteriores al      \      +-------+       |       |
	  store de C sean percibidos      ----->| B->2  |------>|       |
	  por los siguientes loads              +-------+       |       |
	                                        :       :       +-------+


Y en tercer lugar, una barrera de lectura actúa como un orden parcial sobre
las cargas. Considere la siguiente secuencia de eventos:

	CPU 1			CPU 2
	=======================	=======================
		{ A = 0, B = 9 }
	STORE A=1
	<barrera de escritura>
	STORE B=2
				LOAD B
				LOAD A

Sin intervención, la CPU 2 puede elegir percibir los eventos en la CPU 1 en
algún orden aleatorio a efectos prácticos, a pesar de la barrera de
escritura emitida por la CPU 1:

	+-------+       :      :                :       :
	|       |       +------+                +-------+
	|       |------>| A=1  |------      --->| A->0  |
	|       |       +------+      \         +-------+
	| CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
	|       |       +------+        |       +-------+
	|       |------>| B=2  |---     |       :       :
	|       |       +------+   \    |       :       :       +-------+
	+-------+       :      :    \   |       +-------+       |       |
	                             ---------->| B->2  |------>|       |
	                                |       +-------+       | CPU 2 |
	                                |       | A->0  |------>|       |
	                                |       +-------+       |       |
	                                |       :       :       +-------+
	                                 \      :       :
	                                  \     +-------+
	                                   ---->| A->1  |
	                                        +-------+
	                                        :       :

Sin embargo, si se colocara una barrera de lectura entre la carga de B y la
carga de A en la CPU 2:

	CPU 1			CPU 2
	=======================	=======================
		{ A = 0, B = 9 }
	STORE A=1
	<barrera de escritura>
	STORE B=2
				LOAD B
				<barrera de lectura>
				LOAD A

entonces el orden parcial impuesto por la CPU 1 será percibido
correctamente por la CPU 2:

	+-------+       :      :                :       :
	|       |       +------+                +-------+
	|       |------>| A=1  |------      --->| A->0  |
	|       |       +------+      \         +-------+
	| CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
	|       |       +------+        |       +-------+
	|       |------>| B=2  |---     |       :       :
	|       |       +------+   \    |       :       :       +-------+
	+-------+       :      :    \   |       +-------+       |       |
	                             ---------->| B->2  |------>|       |
	                                |       +-------+       | CPU 2 |
	                                |       :       :       |       |
	                                |       :       :       |       |
	  En este punto la barrera ----> \  rrrrrrrrrrrrrrrrr   |       |
	  de lectura consigue que         \     +-------+       |       |
	  todos los efectos anteriores     ---->| A->1  |------>|       |
	  al almacenamiento de B sean           +-------+       |       |
	  perceptibles por la CPU 2             :       :       +-------+


Para ilustrar esto de manera más completa, considere lo que podría pasar si
el código contenía una carga de A a cada lado de la barrera de lectura:

	CPU 1			CPU 2
	=======================	=======================
		{ A = 0, B = 9 }
	STORE A=1
	<barrera de escritura>
	STORE B=2
				LOAD B
				LOAD A [primer load de A]
				<rbarrera de lectura>
				LOAD A [segundo load de A]

Aunque las dos cargas de A ocurren después de la carga de B, ambas pueden
obtener diferentes valores:

	+-------+       :      :                :       :
	|       |       +------+                +-------+
	|       |------>| A=1  |------      --->| A->0  |
	|       |       +------+      \         +-------+
	| CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
	|       |       +------+        |       +-------+
	|       |------>| B=2  |---     |       :       :
	|       |       +------+   \    |       :       :       +-------+
	+-------+       :      :    \   |       +-------+       |       |
	                             ---------->| B->2  |------>|       |
	                                |       +-------+       | CPU 2 |
	                                |       :       :       |       |
	                                |       :       :       |       |
	                                |       +-------+       |       |
	                                |       | A->0  |------>| 1st   |
	                                |       +-------+       |       |
	  En este punto la barrera ----> \  rrrrrrrrrrrrrrrrr   |       |
	  de lectura consigue que         \     +-------+       |       |
	  todos los efectos anteriores     ---->| A->1  |------>|       |
	  al almacenamiento de B sean           +-------+       |       |
	  perceptibles por la CPU 2             :       :       +-------+

Pero puede ser que la actualización a A desde la CPU 1 se vuelva
perceptible para la CPU 2 antes de que la barrera de lectura se complete de
todos modos:

	+-------+       :      :                :       :
	|       |       +------+                +-------+
	|       |------>| A=1  |------      --->| A->0  |
	|       |       +------+      \         +-------+
	| CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
	|       |       +------+        |       +-------+
	|       |------>| B=2  |---     |       :       :
	|       |       +------+   \    |       :       :       +-------+
	+-------+       :      :    \   |       +-------+       |       |
	                             ---------->| B->2  |------>|       |
	                                |       +-------+       | CPU 2 |
	                                |       :       :       |       |
	                                 \      :       :       |       |
	                                  \     +-------+       |       |
	                                   ---->| A->1  |------>| 1st   |
	                                        +-------+       |       |
	                                    rrrrrrrrrrrrrrrrr   |       |
	                                        +-------+       |       |
	                                        | A->1  |------>| 2nd   |
	                                        +-------+       |       |
	                                        :       :       +-------+

La garantía es que la segunda carga siempre dará como resultado A == 1 si
la carga de B resultó en B == 2. No existe tal garantía para la primera
carga de A; esto puede dar como resultado A == 0 o A == 1.


BARRERAS DE MEMORIA DE LECTURA FRENTE A ESPECULACIÓN DE CARGA
-------------------------------------------------------------

Muchas CPU especulan con las cargas: es decir, ven que necesitarán cargar
un elemento de la memoria, y encuentran un momento en el que no están
usando el bus para ningún otra carga, y también en la carga por adelantado,
aunque en realidad no lo hayan llegado a ese punto en el flujo de ejecución
de instrucciones todavía. Esto permite que la instrucción de carga real
potencialmente complete de inmediato, porque la CPU ya tiene el valor a
mano.

Puede resultar que la CPU en realidad no necesitara el valor, tal vez
porque una condición eludió la carga, en cuyo caso puede descartar el valor
o simplemente almacenar en caché para su uso posterior.

Considere:

	CPU 1			CPU 2
	=======================	=======================
				LOAD B
				DIVIDE		} Instrucciones de división
				DIVIDE		} tardan mucho en terminar
				LOAD A

donde DIVIDE es DIVIDIR. Que podría aparecer como esto:

	                                        :       :       +-------+
	                                        +-------+       |       |
	                                    --->| B->2  |------>|       |
	                                        +-------+       | CPU 2 |
	                                        :       :DIVIDE |       |
	                                        +-------+       |       |
	La CPU ocupada con la división ---> --->| A->0  |~~~~   |       |
	especula sobre el LOAD de A             +-------+   ~   |       |
	                                        :       :   ~   |       |
	                                        :       :DIVIDE |       |
	                                        :       :   ~   |       |
	Una vez completadas las divisiones  --> :       :   ~-->|       |
	la CPU puede realizar el                :       :       |       |
	LOAD con efecto inmediato               :       :       +-------+


Colocando una barrera de lectura o una barrera de dependencia de dirección
justo antes de la segundo carga:



	CPU 1			CPU 2
	=======================	=======================
				LOAD B
				DIVIDE
				DIVIDE
				<rbarrera de lectura>
				LOAD A

obligará a reconsiderar cualquier valor obtenido especulativamente en una
medida dependiente del tipo de barrera utilizada. Si no se hizo ningún
cambio en la ubicación de memoria especulada, entonces el valor especulado
solo se usará:

	                                        :       :       +-------+
	                                        +-------+       |       |
	                                    --->| B->2  |------>|       |
	                                        +-------+       | CPU 2 |
	                                        :       :DIVIDE |       |
	                                        +-------+       |       |
  La CPU ocupada con la división ---> --->| A->0  |~~~~   |       |
  especula sobre el LOAD de A             +-------+   ~   |       |
	                                        :       :   ~   |       |
	                                        :       :DIVIDE |       |
	                                        :       :   ~   |       |
	                                        :       :   ~   |       |
	                                    rrrrrrrrrrrrrrrr~   |       |
	                                        :       :   ~   |       |
	                                        :       :   ~-->|       |
	                                        :       :       |       |
	                                        :       :       +-------+


pero si había una actualización o una invalidación de otra CPU pendiente,
entonces la especulación será cancelada y el valor recargado:

	                                        :       :       +-------+
	                                        +-------+       |       |
	                                    --->| B->2  |------>|       |
	                                        +-------+       | CPU 2 |
	                                        :       :DIVIDE |       |
	                                        +-------+       |       |
  La CPU ocupada con la división ---> --->| A->0  |~~~~   |       |
  especula sobre el LOAD de A             +-------+   ~   |       |
	                                        :       :   ~   |       |
	                                        :       :DIVIDE |       |
	                                        :       :   ~   |       |
	                                        :       :   ~   |       |
	                                    rrrrrrrrrrrrrrrrr   |       |
	                                        +-------+       |       |
	La especulación es descartada --->  --->| A->1  |------>|       |
	y un valor actualizado                  +-------+       |       |
	es conseguido                           :       :       +-------+

ATOMICIDAD MULTICOPIA
---------------------

La atomicidad multicopia es una noción profundamente intuitiva sobre el
orden que no es siempre proporcionada por los sistemas informáticos reales,
a saber, que un determinada store se vuelve visible al mismo tiempo para
todos las CPU o, alternativamente, que todas las CPU acuerdan el orden en
que todos los stores se vuelven visibles. Sin embargo, el soporte para
atomicidad multicopia completa descartaría valiosas optimizaciones
hardware, por lo que una versión más débil conocida como ``otra atomicidad
multicopia'' en cambio, solo garantiza que un store dado se vuelva visible
al mismo tiempo en todas las -otras- CPUs. El resto de este documento
discute esta versión más débil, pero por brevedad lo llamaremos simplemente
``atomicidad multicopia''.

El siguiente ejemplo demuestra la atomicidad multicopia:

	CPU 1			CPU 2			CPU 3
	=======================	=======================	=======================
		{ X = 0, Y = 0 }
	STORE X=1		r1=LOAD X (reads 1)	LOAD Y (reads 1)
				<barrera general>	<barrera de lectura>
				STORE Y=r1		LOAD X

Suponga que la carga de la CPU 2 desde X devuelve 1, que luego almacena en
Y, y la carga de la CPU 3 desde Y devuelve 1. Esto indica que el store de
la CPU 1 a X precede a la carga de la CPU 2 desde X y el store de esa CPU 2
a Y precede la carga de la CPU 3 desde Y. Además, las barreras de memoria
garantizan que la CPU 2 ejecuta su carga antes que su almacenamiento, y la
CPU 3 carga desde Y antes de cargar desde X. La pregunta entonces es
"¿Puede la carga de la CPU 3 desde X devolver 0?"

Debido a que la carga de la CPU 3 desde X en cierto sentido viene después
de la carga de la CPU 2, es natural esperar que la carga de la CPU 3 desde
X deba devolver 1. Esta expectativa se deriva de la atomicidad multicopia:
si una carga que se ejecuta en la CPU B sigue una carga de la misma
variable que se ejecuta en la CPU A (y la CPU A no almacenó originalmente
el valor que leyó), entonces en sistemas atómicos multicopia, la carga de
la CPU B debe devolver el mismo valor que hizo la carga de la CPU A o algún
valor posterior. Sin embargo, el kernel Linux no requiere que los sistemas
sean atómicos multicopia.

El uso de una barrera de memoria general en el ejemplo anterior compensa
cualquier falta de atomicidad multicopia. En el ejemplo, si la carga de la
CPU 2 de X devuelve 1 y la carga de la CPU 3 de Y devuelve 1, entonces la
carga de la CPU 3 desde X debe de hecho también devolver 1.

Sin embargo, las dependencias, las barreras de lectura y las barreras de
escritura no siempre son capaces de compensar la atomicidad no multicopia.
Por ejemplo, supongamos que la barrera general de la CPU 2 se elimina del
ejemplo anterior, dejando solo la dependencia de datos que se muestra a
continuación:

	CPU 1			CPU 2			CPU 3
	=======================	=======================	=======================
		{ X = 0, Y = 0 }
	STORE X=1		r1=LOAD X (escribe 1)	LOAD Y (lee 1)
				<dependencia de datos>	<barrera de lectura>
				STORE Y=r1		LOAD X (lee 0)

Esta sustitución permite que la atomicidad no multicopia se desenfrene: en
este ejemplo, es perfectamente legal que la carga de la CPU 2 desde X
devuelva 1, la carga de la CPU 3 desde Y devuelva 1, y su carga desde X
tenga valor 0.

El punto clave es que aunque la dependencia de datos de la CPU 2 ordena su
carga y store, no garantiza ordenar el store de la CPU 1. De forma que, si
este ejemplo se ejecuta en un sistema atómico no multicopia donde las CPU 1
y 2 comparten un buffer de almacenamiento o un nivel de caché, la CPU 2
podría tener acceso anticipado de escritura a CPU 1. Por lo tanto, se
requieren barreras generales para garantizar que todas las CPU acurden el
orden combinado de accesos múltiples.

Las barreras generales pueden compensar no solo la atomicidad no
multicopia, pero también pueden generar orden adicional que puede asegurar
que -todas- las CPU percibirán el mismo orden de -todas- las operaciones.
Por el contrario, una cadena de parejas de liberación-adquisición no
proporciona este orden adicional, lo que significa que solo se garantiza
que las CPU de la cadena estén de acuerdo en el orden combinado de los
accesos. Por ejemplo, cambiando a código C en deferencia al fantasma de
Herman Hollerith:

	int u, v, x, y, z;

	void cpu0(void)
	{
		r0 = smp_load_acquire(&x);
		WRITE_ONCE(u, 1);
		smp_store_release(&y, 1);
	}

	void cpu1(void)
	{
		r1 = smp_load_acquire(&y);
		r4 = READ_ONCE(v);
		r5 = READ_ONCE(u);
		smp_store_release(&z, 1);
	}

	void cpu2(void)
	{
		r2 = smp_load_acquire(&z);
		smp_store_release(&x, 1);
	}

	void cpu3(void)
	{
		WRITE_ONCE(v, 1);
		smp_mb();
		r3 = READ_ONCE(u);
	}

Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas
smp_store_release()/smp_load_acquire(), el siguiente resultado estaría
prohibido:

	r0 == 1 && r1 == 1 && r2 == 1

Además, debido a la relación liberación-adquisición entre cpu0() y cpu1(),
cpu1() debe ver las escrituras de cpu0(), de modo que el siguiente
resultado estaría prohibido:

	r1 == 1 && r5 == 0

Sin embargo, el orden proporcionado por una cadena de
liberación-adquisición es local a las CPU que participan en esa cadena y no
se aplica a cpu3(), al menos aparte de los stores. Por lo tanto, es posible
el siguiente resultado:

	r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0

Por otro lado, también el siguiente resultado es posible:

	r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 && r5 == 1

Aunque cpu0(), cpu1() y cpu2() verán sus respectivas lecturas y escrituras
en orden, las CPU que no participan en la cadena de liberación-adquisición
pueden estar en desacuerdo con el orden. Este desacuerdo se debe al hecho
de que las instrucciones de barrera de memoria débiles utilizadas para
implementar smp_load_acquire() y smp_store_release() no son necesarios para
ordenar stores anteriores contra cargas posteriores en todos los casos.
Esto significa que cpu3() puede ver el store de cpu0() suceder -después- de
la carga de cpu1() desde v, aunque tanto cpu0() como cpu1() están de
acuerdo en que estas dos operaciones ocurrieron en el orden previsto.

Sin embargo, tenga en cuenta que smp_load_acquire() no es mágico. En
particular, simplemente lee de su argumento en orden. Es decir, -no-
asegura que se leerá cualquier valor en particular. Por lo tanto, los
siguiente resultados son posibles:

	r0 == 0 && r1 == 0 && r2 == 0 && r5 == 0

Tenga en cuenta que este resultado puede ocurrir incluso en un mítico
sistema, consistente en secuencia, donde nunca se reordena nada.

Para reiterar, si su código requiere un orden completo de todas las
operaciones, utilice barreras generales en todo momento.


==============================
BARRERAS EXPLÍCITAS DEL KERNEL
==============================

El kernel Linux tiene una variedad de diferentes barreras que actúan a
diferentes niveles:

  (*) Barrera del compilador.

  (*) Barreras de memoria de la CPU.


BARRERA DEL COMPILADOR
-----------------------

El kernel de Linux tiene una función de barrera del compilador explícita
que evita que el el compilador mueva los accesos a la memoria de cualquier
lado al otro:

	barrier();

Esta es una barrera general: no hay variantes de barrier() para casos de
lectura-lectura o escritura-escritura. Sin embargo, READ_ONCE() y
WRITE_ONCE() pueden ser considerado como formas débiles de barrier() que
afectan solo específicos accesos marcados por READ_ONCE() o WRITE_ONCE().

La función barrier() produce los siguientes efectos:

 (*) Evita que el compilador reordene los accesos tras barrier() para
     preceder a cualquier acceso que preceda a barrier(). Un ejemplo de uso
     de esta propiedad es facilitar la comunicación entre código del
     interrupt-handler (encargo de gestionar interrupciones) y el código
     que fue interrumpido.

 (*) Dentro de un bucle ("loop"), obliga al compilador a cargar las
     variables utilizadas en ese loop condicional en cada paso a través de
     ese loop.

Las funciones READ_ONCE() y WRITE_ONCE() pueden evitar cualquier cantidad
de optimizaciones que, si bien son perfectamente seguras en código de un
solo subproceso, pueden resultar fatales en código concurrente. Aquí hay
algunos ejemplos de tal tipo de optimizaciones:

(*) El compilador está en su derecho de reordenar cargas y stores de la
    misma variable, y en algunos casos, la CPU está dentro de su
    derecho de reordenar cargas a la misma variable. Esto significa que
    el siguiente código:

 a[0] = x;
 a[1] = x;

     Podría resultar en un valor más antiguo de x almacenado en a[1] que en
     a[0]. Evite que tanto el compilador como la CPU hagan esto de la
     siguiente manera:

	a[0] = READ_ONCE(x);
	a[1] = READ_ONCE(x);

     En resumen, READ_ONCE() y WRITE_ONCE() proporcionan coherencia de
     caché para accesos desde múltiples CPUs a una sola variable.

     (*) El compilador tiene derecho a juntar cargas sucesivas de la misma
         variable. Tal fusión puede hacer que el compilador "optimice" el
         siguiente código:

    	while (tmp = a)
    		hacer_algo_con(tmp);

        en el siguiente código, que, aunque en cierto sentido es legítimo
        para un código de un solo subproceso, es casi seguro que no es lo
        que el desarrollador pretendía:

   	if (tmp = a)
   		for (;;)
   			hacer_algo_con(tmp);

        Use READ_ONCE() para evitar que el compilador le haga esto:

   	while (tmp = READ_ONCE(a))
   		hacer_algo_con(tmp);

 (*) El compilador tiene derecho a recargar una variable, por ejemplo,
    en los casos en que la alta presión de los registros impida que el
    compilador mantenga todos los datos de interés en registros. El
    compilador podría por lo tanto, optimizar la variable 'tmp' de nuestro
    ejemplo anterior:

	while (tmp = a)
		hacer_algo_con(tmp);

     Esto podría resultar en el siguiente código, que es perfectamente
     seguro en código de subproceso único, pero puede ser fatal en código
     concurrente:

	while (a)
		hacer_algo_con(a);

    Por ejemplo, la versión optimizada de este código podría resultar en
    pasar un cero a hacer_algo_con() en el caso de que la variable a sea
    modificada por alguna otra CPU, entre la instrucción "while" y la
    llamada a hacer_algo_con().

    De nuevo, use READ_ONCE() para evitar que el compilador haga esto:

	while (tmp = READ_ONCE(a))
		hacer_algo_con(tmp);

     Tenga en cuenta que si el compilador se queda sin registros, podría
     guardar tmp en la pila ("stack"). El overhead (coste en eficiencia) de
     este guardado y posterior restauración es por lo que los compiladores
     recargan las variables. Hacerlo es perfectamente seguro para código de
     subproceso único, por lo que debe informar al compilador sobre los
     casos donde no sea seguro.

 (*) El compilador está en su derecho de omitir una carga por completo si
     sabe cual será su valor. Por ejemplo, si el compilador puede probar
     que el valor de la variable 'a' siempre es cero, puede optimizar este
     código:

	while (tmp = a)
		hacer_algo_con(tmp);

     En esto:

	do { } while (0);

     Esta transformación es una victoria para un código de un solo
     subproceso, porque se deshace de una carga y un branch. El problema es
     que el compilador llevará a cabo su prueba asumiendo que la CPU actual
     es la única actualizando la variable 'a'. Si la variable 'a' es
     compartida, entonces la prueba del compilador será errónea. Use
     READ_ONCE() para decirle al compilador que no sabe tanto como cree:

	while (tmp = READ_ONCE(a))
		hacer_algo_con(tmp);

     Pero, por favor, tenga en cuenta que el compilador también está
     observando de cerca lo que usted hace con el valor después de
     READ_ONCE(). Por ejemplo, suponga que Ud. hace lo siguiente y MAX es
     una macro de preprocesador con el valor 1:

	while ((tmp = READ_ONCE(a)) % MAX)
		hacer_algo_con(tmp);

     Entonces el compilador sabe que el resultado del operador "%" aplicado
     a MAX siempre será cero, nuevamente permitiendo que el compilador
     optimice el código hasta su casi inexistencia. (Aún se cargará desde
     la variable 'a'.)

 (*) De manera similar, el compilador tiene derecho a omitir un store por
     completo si sabe que la variable ya tiene el valor almacenado.
     Nuevamente, el compilador asume que la CPU actual es la única que
     almacena la variable, lo que puede hacer que el compilador haga
     algo incorrecto para las variables compartidas. Por ejemplo, suponga
     que tiene lo siguiente:

	a = 0;
	... Código que no almacena la variable a ...
	a = 0;

     El compilador observa que el valor de la variable 'a' ya es cero, por
     lo que bien podría omitir el segundo store. Esto supondría una fatal
     sorpresa, si alguna otra CPU hubiera almacenado la variable 'a'
     mientras tanto.

     Use WRITE_ONCE() para evitar que el compilador haga este tipo de
     suposición equivocada:

	WRITE_ONCE(a, 0);
	... Código que no almacena la variable a  ...
	WRITE_ONCE(a, 0);

  (*) El compilador tiene derecho a reordenar los accesos a memoria a menos
     que le diga que no. Por ejemplo, considere la siguiente interacción
     entre el código de nivel de proceso y un controlador de interrupción:

	void nivel_de_procesamiento(void)
	{
		msg = ACQUIRE_mensaje();
		flag = true;
	}

	void controlador_interrupcion(void)
	{
		if (flag)
			procesar_mensaje(msg);
	}

     No hay nada que impida que el compilador transforme
     nivel_de_procesamiento() a lo siguiente, que de hecho, bien podría ser
     una victoria para código de un solo subproceso:

	void nivel_de_procesamiento(void)
	{
		flag = true;
		msg = ACQUIRE_mensaje();
	}

     Si la interrupción ocurre entre estas dos declaraciones, entonces
     controlador_interrupcion() podría recibir un mensaje ilegible. Use
     READ_ONCE() para evitar esto de la siguiente manera:

	void nivel_de_procesamiento(void)
	{
		WRITE_ONCE(msg, ACQUIRE_mensaje());
		WRITE_ONCE(flag, true);
	}

	void controlador_interrupcion(void)
	{
		if (READ_ONCE(flag))
			procesar_mensaje(READ_ONCE(msg));
	}

     Tenga en cuenta que los envoltorios ("wrappers") READ_ONCE() y
     WRITE_ONCE() en controlador_interrupcion() son necesarios si este
     controlador de interrupciones puede ser interrumpido por algo que
     también accede a 'flag' y 'msg', por ejemplo, una interrupción anidada
     o un NMI. De lo contrario, READ_ONCE() y WRITE_ONCE() no son
     necesarios en controlador_interrupcion() aparte de con fines de
     documentación. (Tenga también en cuenta que las interrupciones
     anidadas no ocurren típicamente en los kernels Linux modernos, de
     hecho, si un controlador de interrupciones regresa con interrupciones
     habilitadas, obtendrá un WARN_ONCE().)

     Debe suponer que el compilador puede mover READ_ONCE() y WRITE_ONCE()
     a código que no contiene READ_ONCE(), WRITE_ONCE(), barrier(), o
     primitivas similares.

     Este efecto también podría lograrse usando barrier(), pero READ_ONCE()
     y WRITE_ONCE() son más selectivos: Con READ_ONCE() y WRITE_ONCE(), el
     compilador solo necesita olvidar el contenido de ubicaciones de
     memoria indicadas, mientras que con barrier() el compilador debe
     descartar el valor de todas las ubicaciones de memoria que tiene
     actualmente almacenadas en caché, en cualquier registro de la máquina.
     Por supuesto, el compilador también debe respetar el orden en que
     ocurren READ_ONCE() y WRITE_ONCE(), aunque la CPU, efectivamente, no
     necesita hacerlo.

 (*) El compilador tiene derecho a inventar stores para una variable,
     como en el siguiente ejemplo:

	if (a)
		b = a;
	else
		b = 42;

    El compilador podría ahorrar un branch al optimizar esto de la
    siguiente manera:

    	b = 42;
    	if (a)
    		b = a;

     En el código de un solo subproceso, esto no solo es seguro, sino que
     también ahorra un branch. Desafortunadamente, en código concurrente,
     esta optimización podría causar que alguna otra CPU vea un valor falso
     de 42, incluso si la variable 'a' nunca fue cero, al cargar la
     variable 'b'. Use WRITE_ONCE() para evitar esto de la siguiente
     manera:

	if (a)
		WRITE_ONCE(b, a);
	else
		WRITE_ONCE(b, 42);

    El compilador también puede inventar cargas. Estos casos suelen ser
    menos perjudiciales, pero pueden dar como resultado "bouncing" de la
    línea de caché y, por lo tanto, bajo rendimiento y escalabilidad.
    Utilice READ_ONCE() para evitar cargas inventadas.

 (*) Para ubicaciones de memoria alineadas cuyo tamaño les permita
     acceder con una sola instrucción de referencia de memoria, evite el
     "desgarro de la carga" (load tearing) y "desgarro del store" (store
     tearing), en el que un solo gran acceso es reemplazado por múltiples
     accesos menores. Por ejemplo, dada una arquitectura que tiene
     instrucciones de almacenamiento de 16 bits con campos inmediatos de 7
     bits, el compilador podría tener la tentación de usar dos
     instrucciones inmediatas de almacenamiento de 16 bits para implementar
     el siguiente store de 32 bits:

	p = 0x00010002;

     Tenga en cuenta que GCC realmente usa este tipo de optimización, lo
     cual no es sorprendente dado que probablemente costaría más de dos
     instrucciones el construir la constante y luego almacenarla. Por lo
     tanto, esta optimización puede ser una victoria en un código de un
     solo subproceso. De hecho, un error reciente (desde que se solucionó)
     hizo que GCC usara incorrectamente esta optimización en un store
     volátil. En ausencia de tales errores, el uso de WRITE_ONCE() evita el
     desgarro del store en el siguiente ejemplo:

	struct __attribute__((__packed__)) foo {
		short a;
		int b;
		short c;
	};
	struct foo foo1, foo2;
	...

	foo2.a = foo1.a;
	foo2.b = foo1.b;
	foo2.c = foo1.c;

     Debido a que no hay envoltorios READ_ONCE() o WRITE_ONCE() y no
     hay markings volátiles, el compilador estaría en su derecho de
     implementar estas tres declaraciones de asignación como un par de
     cargas de 32 bits, seguido de un par de stores de 32 bits. Esto
     resultaría en una carga con desgarro en 'foo1.b' y store del desgarro
     en 'foo2.b'. READ_ONCE() y WRITE_ONCE() nuevamente evitan el desgarro
     en este ejemplo:

	foo2.a = foo1.a;
	WRITE_ONCE(foo2.b, READ_ONCE(foo1.b));
	foo2.c = foo1.c;

Aparte de esto, nunca es necesario usar READ_ONCE() y WRITE_ONCE() en una
variable que se ha marcado como volátil. Por ejemplo, dado que 'jiffies'
está marcado como volátil, nunca es necesario usar READ_ONCE(jiffies). La
razón de esto es que READ_ONCE() y WRITE_ONCE() se implementan como
conversiones volátiles, lo que no tiene efecto cuando su argumento ya está
marcado como volátil.

Tenga en cuenta que estas barreras del compilador no tienen un efecto
directo en la CPU, que luego puede reordenar las cosas como quiera.


BARRERAS DE MEMORIA DE LA CPU
-----------------------------

El kernel de Linux tiene siete barreras básicas de memoria de CPU:

TIPO			OBLIGATORIO	SMP CONDICIONAL
=======================	===============	===============
GENERAL			mb()		smp_mb()
WRITE			wmb()		smp_wmb()
READ			rmb()		smp_rmb()
DEPEDENCIA DE DIRECCIÓN			READ_ONCE()


Todas las barreras de memoria, excepto las barreras de dependencia de
direcciones, implican una barrera del compilador. Las dependencias de
direcciones no imponen ningún orden de compilación adicional.

Además: en el caso de las dependencias de direcciones, se esperaría que el
compilador emita las cargas en el orden correcto (por ejemplo, `a[b]`
tendría que cargar el valor de b antes de cargar a[b]), sin embargo, no hay
garantía alguna en la especificación de C sobre que el compilador no puede
especular el valor de b (por ejemplo, es igual a 1) y carga a[b] antes que
b (ej. tmp = a[1]; if (b != 1) tmp = a[b]; ). También existe el problema de
que un compilador vuelva a cargar b después de haber cargado a[b], teniendo
así una copia más nueva de b que a[b]. Aún no se ha conseguido un consenso
acerca de estos problemas, sin embargo, el macro READ_ONCE() es un buen
lugar para empezar a buscar.

Las barreras de memoria SMP se reducen a barreras de compilador cuando se
compila a monoprocesador, porque se supone que una CPU parecerá ser
auto-consistente, y ordenará correctamente los accesos superpuestos
respecto a sí misma. Sin embargo, consulte la subsección "Guests de
máquinas virtuales" mas adelante.

[!] Tenga en cuenta que las barreras de memoria SMP _deben_ usarse para
controlar el orden de referencias a memoria compartida en sistemas SMP,
aunque el uso de bloqueo en su lugar sea suficiente.

Las barreras obligatorias no deben usarse para controlar los efectos de
SMP, ya que dichas barreras imponen una sobrecarga innecesaria en los
sistemas SMP y UP. Se pueden, sin embargo, usar para controlar los efectos
MMIO en los accesos a través de ventanas E/S de memoria relajada. Estas
barreras son necesarias incluso en sistemas que no son SMP, ya que afectan
al orden en que las operaciones de memoria aparecen en un dispositivo, al
prohibir tanto al compilador como a la CPU que sean reordenados.


Hay algunas funciones de barrera más avanzadas:

 (*) smp_store_mb(var, valor)

     Asigna el valor a la variable y luego inserta una barrera de memoria
     completa después de ella. No se garantiza insertar nada más que una
     barrera del compilador en una compilación UP.


 (*) smp_mb__before_atomic();
 (*) smp_mb__after_atomic();

     Estos se pueden usar con funciones RMW atómicas que no implican
     barreras de memoria, pero donde el código necesita una barrera de
     memoria. Ejemplos de funciones RMW atómicas que no implican una
     barrera de memoria son, por ejemplo, agregar, restar, operaciones
     condicionales (fallidas), funciones _relaxed, pero no atomic_read o
     atomic_set. Un ejemplo común donde se puede requerir una barrera es
     cuando se usan operaciones atómicas como referencia de contador.

     Estos también se utilizan para funciones atómicas RMW bitop que no
     implican una barrera de memoria (como set_bit y clear_bit).

     Como ejemplo, considere una pieza de código que marca un objeto como
     muerto y luego disminuye el contador de referencias del objeto:

	obj->dead = 1;
	smp_mb__before_atomic();
	atomic_dec(&obj->ref_count);

     Esto asegura que la marca de muerte en el objeto se perciba como
     fijada *antes* de que disminuya el contador de referencia.

     Consulte Documentation/atomic_{t,bitops}.txt para obtener más
     información.


 (*) dma_wmb();
 (*) dma_rmb();
 (*) dma_mb();

     Estos son usados con memoria consistente para garantizar el orden de
     escrituras o lecturas de memoria compartida accesible tanto para la
     CPU como para un dispositivo compatible con DMA.

     Por ejemplo, considere un controlador de dispositivo que comparte
     memoria con otro dispositivo y usa un valor de estado del descriptor
     para indicar si el descriptor pertenece al dispositivo o a la CPU, y
     un "doorbell" (timbre, punto de acceso) para avisarle cuando haya
     nuevos descriptores disponibles:

	if (desc->status != DEVICE_OWN) {
		/* no leer los datos hasta que tengamos el descriptor */
		dma_rmb();

		/* leer/modificar datos */
		read_data = desc->data;
		desc->data = write_data;

		/* flush de modificaciones antes de la actualización de estado */
		dma_wmb();

		/* asignar propiedad */
		desc->status = DEVICE_OWN;

		/* notificar al dispositivo de nuevos descriptores */
		writel(DESC_NOTIFY, doorbell);
	}

     El dma_rmb() nos permite garantizar que el dispositivo ha liberado su
     propiedad antes de que leamos los datos del descriptor, y el dma_wmb()
     permite garantizar que los datos se escriben en el descriptor antes de
     que el dispositivo pueda ver que ahora tiene la propiedad. El dma_mb()
     implica tanto un dma_rmb() como un dma_wmb(). Tenga en cuenta que, al
     usar writel(), no se necesita un wmb() anterior para garantizar que
     las escrituras de la memoria caché coherente se hayan completado antes
     escribiendo a la región MMIO. El writel_relaxed() más barato no
     proporciona esta garantía y no debe utilizarse aquí.

     Consulte la subsección "Efectos de barrera de E/S del kernel" para
     obtener más información sobre accesorios de E/S relajados y el archivo
     Documentation/core-api/dma-api.rst para más información sobre memoria
     consistente.

 (*) pmem_wmb();

     Es es para uso con memoria persistente para garantizar que los stores
     para los que las modificaciones se escriben en el almacenamiento
     persistente llegaron a dominio de durabilidad de la plataforma.

     Por ejemplo, después de una escritura no temporal en la región pmem,
     usamos pmem_wmb() para garantizar que los stores hayan alcanzado el
     dominio de durabilidad de la plataforma. Esto garantiza que los stores
     han actualizado el almacenamiento persistente antes de cualquier
     acceso a datos o transferencia de datos causada por instrucciones
     posteriores. Esto es además del orden realizado por wmb().

     Para la carga desde memoria persistente, las barreras de memoria de
     lectura existentes son suficientes para garantizar el orden de
     lectura.

 (*) io_stop_wc();

     Para accesos a memoria con atributos de combinación de escritura (por
     ejemplo, los devueltos por ioremap_wc(), la CPU puede esperar a que
     los accesos anteriores se junten con posteriores. io_stop_wc() se
     puede utilizar para evitar la combinación de accesos a memoria de
     de escritura antes de esta macro, con los posteriores, cuando dicha
     espera tenga implicaciones en el rendimiento.

=========================================
BARRERAS DE MEMORIA IMPLÍCITAS DEL KERNEL
=========================================

Algunas de las otras funciones en el kernel Linux implican barreras de
memoria, entre estas encontramos funciones de bloqueo y planificación
("scheduling").

Esta especificación es una garantía _mínima_; cualquier arquitectura
particular puede proporcionar garantías más sustanciales, pero no se puede
confiar en estas fuera de código específico de arquitectura.


FUNCIONES DE ADQUISICIÓN DE CERROJO
-----------------------------------

El kernel Linux tiene una serie de abstracciones de bloqueo:

 (*) spin locks (cerrojos en loop)
 (*) R/W spin lock (cerrojos de escritura/lectura)
 (*) mutex
 (*) semáforos
 (*) R/W semáforos

En todos los casos existen variantes de las operaciones "ACQUIRE" y
"RELEASE" para cada uno de ellos. Todas estas operaciones implican ciertas
barreras:

 (1) Implicaciones de la operación ACQUIRE:

     Las operaciones de memoria emitidas después del ACQUIRE se completarán
     después de que la operación ACQUIRE haya finalizado.

     Las operaciones de memoria emitidas antes de ACQUIRE pueden
     completarse después que la operación ACQUIRE se ha completado.

 (2) Implicaciones de la operación RELEASE:

     Las operaciones de memoria emitidas antes de la RELEASE se
     completarán antes de que la operación de RELEASE se haya completado.

     Las operaciones de memoria emitidas después de la RELEASE pueden
     completarse antes de que la operación de RELEASE se haya completado.

 (3) Implicación de ACQUIRE vs ACQUIRE:

     Todas las operaciones ACQUIRE emitidas antes de otra operación
     ACQUIRE serán completadas antes de esa operación ACQUIRE.

 (4) Implicación de ACQUIRE vs RELEASE:

     Todas las operaciones ACQUIRE emitidas antes de una operación RELEASE
     serán completadas antes de la operación RELEASE.

 (5) Implicación de ACQUIRE condicional fallido:

     Ciertas variantes de bloqueo de la operación ACQUIRE pueden fallar, ya
     sea debido a no poder obtener el bloqueo de inmediato, o debido a que
     recibieron una señal de desbloqueo mientras dormían esperando que el
     cerrojo estuviera disponible. Los fallos en cerrojos no implican
     ningún tipo de barrera.

[!] Nota: una de las consecuencias de que los cerrojos en ACQUIRE y RELEASE
sean barreras unidireccionales, es que los efectos de las instrucciones
fuera de una sección crítica pueden filtrarse al interior de la sección
crítica.

No se puede suponer que un ACQUIRE seguido de una RELEASE sea una barrera
de memoria completa dado que es posible que un acceso anterior a ACQUIRE
suceda después del ACQUIRE, y un acceso posterior a la RELEASE suceda antes
del RELEASE, y los dos accesos puedan entonces cruzarse:

	*A = a;
	ACQUIRE M
	RELEASE M
	*B = b;

puede ocurrir como:

	ACQUIRE M, STORE *B, STORE *A, RELEASE M

Cuando ACQUIRE y RELEASE son bloqueo de adquisición y liberación,
respectivamente, este mismo orden puede ocurrir si el cerrojo ACQUIRE y
RELEASE son para la misma variable de bloqueo, pero solo desde la
perspectiva de otra CPU que no tiene ese bloqueo. En resumen, un ACQUIRE
seguido de un RELEASE NO puede entenderse como una barrera de memoria
completa.

De manera similar, el caso inverso de un RELEASE seguido de un ACQUIRE no
implica una barrera de memoria completa. Por lo tanto, la ejecución de la
CPU de los tramos críticos correspondientes a la RELEASE y la ACQUIRE
pueden cruzarse, de modo que:

	*A = a;
	RELEASE M
	ACQUIRE N
	*B = b;

puede ocurrir como:

	ACQUIRE N, STORE *B, STORE *A, RELEASE M

Podría parecer que este nuevo orden podría introducir un punto muerto.
Sin embargo, esto no puede suceder porque si tal punto muerto amenazara
con suceder, el RELEASE simplemente se completaría, evitando así el
interbloqueo ("deadlock", punto muerto).

	¿Por qué funciona esto?

	Un punto clave es que solo estamos hablando de la CPU re-haciendo el
  orden, no el compilador. Si el compilador (o, ya puestos, el
  desarrollador) cambió las operaciones, un deadlock -podría- ocurrir.

	Pero supongamos que la CPU reordenó las operaciones. En este caso, el
	desbloqueo precede al bloqueo en el código ensamblador. La CPU
  simplemente eligió intentar ejecutar primero la última operación de
  bloqueo. Si hay un interbloqueo, esta operación de bloqueo simplemente
  esperará (o tratará de dormir, pero hablaremos de eso más adelante). La
  CPU eventualmente ejecutará la operación de desbloqueo (que precedió a la
	operación de bloqueo en el código ensamblador), lo que desenmascará el
  potencial punto muerto, permitiendo que la operación de bloqueo tenga
  éxito.

	Pero, ¿y si el cerrojo es un cerrojo que duerme ("sleeplock")? En tal
  caso, el código intentará entrar al scheduler, donde eventualmente
  encontrará una barrera de memoria, que forzará la operación de desbloqueo
  anterior para completar, nuevamente desentrañando el punto muerto. Podría
	haber una carrera de desbloqueo del sueño ("sleep-unlock race"), pero la
  primitiva de bloqueo necesita resolver tales carreras correctamente en
  cualquier caso.

Es posible que los cerrojos y los semáforos no proporcionen ninguna
garantía de orden en sistemas compilados en UP, por lo que no se puede
contar con tal situación para lograr realmente nada en absoluto,
especialmente con respecto a los accesos de E/S, a menos que se combinen
con operaciones de inhabilitación de interrupciones.

Consulte también la sección "Efectos de barrera adquiriendo intra-CPU".


Como ejemplo, considere lo siguiente:

	*A = a;
	*B = b;
	ACQUIRE
	*C = c;
	*D = d;
	RELEASE
	*E = e;
	*F = f;

La siguiente secuencia de eventos es aceptable:

	ACQUIRE, {*F,*A}, *E, {*C,*D}, *B, RELEASE

  [+] Tenga en cuenta que {*F,*A} indica un acceso combinado.

Pero ninguno de los siguientes lo son:

	{*F,*A}, *B,	ACQUIRE, *C, *D,	RELEASE, *E
	*A, *B, *C,	ACQUIRE, *D,		RELEASE, *E, *F
	*A, *B,		ACQUIRE, *C,		RELEASE, *D, *E, *F
	*B,		ACQUIRE, *C, *D,	RELEASE, {*F,*A}, *E



FUNCIONES DE DESACTIVACIÓN DE INTERRUPCIONES
--------------------------------------------

Las funciones que deshabilitan interrupciones (equivalentes a ACQUIRE) y
habilitan interrupciones (equivalentes a RELEASE) actuarán únicamente como
barrera del compilador. Por consiguiente, si la memoria o la E/S requieren
barreras en tal situación, deben ser provistas por algún otro medio.


FUNCIONES DE DORMIR Y DESPERTAR
-------------------------------

Dormir y despertar son eventos marcados ("flagged") en los datos globales
que se pueden ver como una interacción entre dos piezas de datos: el estado
de la task (hilo, proceso, tarea) que espera el evento y los datos globales
utilizados para indicar el evento. Para asegurarse de que estos parezcan
suceder en el orden correcto, las primitivas para comenzar el proceso de ir
a dormir, y las primitivas para iniciar un despertar implican ciertas
barreras.

En primer lugar, el agente durmiente normalmente sigue algo similar a esta
secuencia de eventos:

	for (;;) {
		set_current_state(TASK_UNINTERRUPTIBLE);
		if (evento_indicado)
			break;
		schedule(); // planificar
	}

Una barrera de memoria general se obtiene automáticamente mediante
set_current_state() después de haber alterado el estado de la tarea:

	CPU 1
	===============================
	set_current_state(); // hacer_estado_actual()
	  smp_store_mb();
	    STORE current->state
	    <barrera general>
	LOAD evento_indicado

set_current_state() puede estar envuelto por:

	prepare_to_wait(); // preparese_para_esperar();
	prepare_to_wait_exclusive(); // prepararse_para_solo_esperar();

que por lo tanto también implican una barrera de memoria general después de
establecer el estado. Toda la secuencia anterior está disponible en varias
formas, todas las cuales obtienen la barrera de memoria en el lugar
correcto:

	wait_event();
	wait_event_interruptible();
	wait_event_interruptible_exclusive();
	wait_event_interruptible_timeout();
	wait_event_killable();
	wait_event_timeout();
	wait_on_bit();
	wait_on_bit_lock();


En segundo lugar, el código que realiza una activación normalmente se
asemeja a algo como esto:

	evento_indicado = 1;
	wake_up(&event_wait_queue); // despertar

o:

	evento_indicado = 1;
	wake_up_process(event_daemon); // despertar proceso

wake_up() ejecuta una barrera de memoria general si despierta algo. Si no
despierta nada, entonces una barrera de memoria puede o no ser ejecutada;
no debe confiar en ello. La barrera se produce antes del acceso al estado
de la tarea. En particular, se encuentra entre el STORE para indicar el
evento y el STORE para configurar TASK_RUNNING (hilo ejecutando):

	CPU 1 (Durmiente)			CPU 2 (Despertadora)
	===============================	===============================
	set_current_state();		STORE evento_indicado
	  smp_store_mb();		wake_up();
	    STORE current->state	  ...
	    <barrera general>		  <barrera general>
	LOAD evento_indicado		  if ((LOAD task->state) & TASK_NORMAL)
					    STORE task->state

donde "task" es el subproceso que se está despertando y es igual al
"current" (hilo actual) de la CPU 1.

Para reiterar, se garantiza la ejecución de una barrera de memoria general
mediante wake_up() si algo está realmente despierto, pero de lo contrario
no existe tal garantía. Para entender esto, considere la siguiente
secuencia de eventos, donde X e Y son ambos cero inicialmente:

	CPU 1				CPU 2
	===============================	===============================
	X = 1;				Y = 1;
	smp_mb();			wake_up();
	LOAD Y				LOAD X

Si ocurre una reactivación ("wakeup"), una (al menos) de las dos cargas
debe ver 1. Si, por otro lado, no ocurre una reactivación, ambas cargas
pueden ver 0.

wake_up_process() siempre ejecuta una barrera de memoria general. La
barrera, de nuevo, ocurre antes de que se acceda al estado del hilo. En
particular, si wake_up(), en el fragmento anterior, fuera reemplazado por
una llamada a wake_up_process(), las dos cargas verían 1, garantizado.

Las funciones de activación disponibles incluyen:

	complete();
	wake_up();
	wake_up_all();
	wake_up_bit();
	wake_up_interruptible();
	wake_up_interruptible_all();
	wake_up_interruptible_nr();
	wake_up_interruptible_poll();
	wake_up_interruptible_sync();
	wake_up_interruptible_sync_poll();
	wake_up_locked();
	wake_up_locked_poll();
	wake_up_nr();
	wake_up_poll();
	wake_up_process();

En términos de orden de la memoria, todas estas funciones proporcionan las
mismas garantías que un wake_up() (o más fuertes).

[!] Tenga en cuenta que las barreras de la memoria implicadas por el
durmiente y el despierto _no_ ordenan varios stores antes del despertar con
respecto a cargas de los valores guardados después de que el durmiente haya
llamado a set_current_state(). Por ejemplo, si el durmiente hace:

	set_current_state(TASK_INTERRUPTIBLE);
	if (evento_indicado)
		break;
	__set_current_state(TASK_RUNNING);
	hacer_algo(my_data);

y el que despierta hace:

	my_data = valor;
	evento_indicado = 1;
	wake_up(&event_wait_queue);

no existe garantía de que el cambio a event_indicated sea percibido por
el durmiente de manera que venga después del cambio a my_data. En tal
circunstancia, el código en ambos lados debe sacar sus propias barreras de
memoria entre los separados accesos a datos. Por lo tanto, el durmiente
anterior debería hacer:

	set_current_state(TASK_INTERRUPTIBLE);
	if (evento_indicado) {
		smp_rmb();
		hacer_algo(my_data);
	}

y el que despierta debería hacer:

	my_data = value;
	smp_wmb();
	evento_indicado = 1;
	wake_up(&event_wait_queue);

FUNCIONES VARIAS
----------------

Otras funciones que implican barreras:

 (*) schedule() y similares implican barreras completas de memoria.


========================================
EFECTOS DE BARRERA ADQUIRIENDO INTRA-CPU
========================================

En los sistemas SMP, las primitivas de bloqueo proveen una forma más
sustancial de barrera: una que afecta el orden de acceso a la memoria en
otras CPU, dentro del contexto de conflicto en cualquier bloqueo en
particular.


ADQUISICIÓN VS ACCESOS A MEMORIA
--------------------------------

Considere lo siguiente: el sistema tiene un par de spinlocks (M) y (Q), y
tres CPU; entonces la siguiente secuencia de eventos debería ocurrir:

	CPU 1				CPU 2
	===============================	===============================
	WRITE_ONCE(*A, a);		WRITE_ONCE(*E, e);
	ACQUIRE M			ACQUIRE Q
	WRITE_ONCE(*B, b);		WRITE_ONCE(*F, f);
	WRITE_ONCE(*C, c);		WRITE_ONCE(*G, g);
	RELEASE M			RELEASE Q
	WRITE_ONCE(*D, d);		WRITE_ONCE(*H, h);

Entonces no hay garantía sobre en qué orden verá la CPU 3 los accesos a *A
hasta que *H ocurra, además de las restricciones impuestas por los bloqueos
separados en las distintas CPUs. Podría, por ejemplo, ver:

	*E, ACQUIRE M, ACQUIRE Q, *G, *C, *F, *A, *B, RELEASE Q, *D, *H, RELEASE M

Pero no verá ninguno de:

	*B, *C or *D preceding ACQUIRE M
	*A, *B or *C following RELEASE M
	*F, *G or *H preceding ACQUIRE Q
	*E, *F or *G following RELEASE Q

========================================
¿DÓNDE SE NECESITAN BARRERAS DE MEMORIA?
========================================

Bajo operación normal, el re-ordenamiento de una operación de memoria
generalmente no va a suponer un problema, ya que para una pieza de código
lineal de un solo subproceso seguirá pareciendo que funciona correctamente,
incluso si está en un kernel SMP. Existen, sin embargo, cuatro
circunstancias en las que reordenar definitivamente _podría_ ser un
problema:

 (*) Interacción entre procesadores.

 (*) Operaciones atómicas.

 (*) Acceso a dispositivos.

 (*) Interrupciones.


INTERACCIÓN ENTRE PROCESADORES
------------------------------

Cuando se da un sistema con más de un procesador, más de una CPU en el
sistema puede estar trabajando en el mismo conjunto de datos al mismo
tiempo. Esto puede causar problemas de sincronización, y la forma habitual
de tratar con estos es utilizar cerrojos. Sin embargo, los cerrojos son
bastante caros, por lo que puede ser preferible operar sin el uso de un
cerrojo a ser posible. En cuyo caso, es posible que las operaciones que
afectan a ambas CPU deban ordenarse cuidadosamente para evitar un
funcionamiento incorrecto.

Considere, por ejemplo, la ruta lenta del semáforo R/W. Aquí hay un proceso
de espera en cola del semáforo, en virtud de que tiene una parte de su pila
vinculada a la lista de procesos en espera del semáforo:

	struct rw_semaphore {
		...
		spinlock_t lock;
		struct list_head waiters;
	};

	struct rwsem_waiter {
		struct list_head list;
		struct task_struct *task;
	};

Para despertar a un proceso que espera ("waiter") en particular, las
funciones up_read() o up_write() tienen que:

 (1) leer el siguiente puntero del registro de este proceso que espera,
     para saber dónde está el registro del siguiente waiter;

 (2) leer el puntero a la estructura de tareas del waiter;

 (3) borrar el puntero de la tarea para decirle al waiter que se le ha dado
     el semáforo;

 (4) llamar a wake_up_process() en la tarea; y

 (5) liberar la referencia retenida en la estructura de tareas del waiter.

En otras palabras, tiene que realizar esta secuencia de eventos:

	LOAD waiter->list.next;
	LOAD waiter->task;
	STORE waiter->task;
	CALL wakeup
	RELEASE task

y si alguno de estos pasos ocurre fuera de orden, entonces todo puede que
funcione defectuosamente.

Una vez que se ha puesto en cola y soltado el bloqueo de semáforo, el
proceso que espera no consigue el candado de nuevo; en cambio, solo espera
a que se borre su puntero de tarea antes de continuar. Dado que el registro
está en la pila del proceso que espera, esto significa que si el puntero de
la tarea se borra _antes_ de que se lea el siguiente puntero de la lista,
otra CPU podría comenzar a procesar el proceso que espera y podría romper
el stack del proceso que espera antes de que la función up*() tenga la
oportunidad de leer el puntero que sigue.

Considere entonces lo que podría suceder con la secuencia de eventos
anterior:

	CPU 1				CPU 2
	===============================	===============================
					down_xxx()
					Poner waiter en la "queue" (cola)
					Dormir
	up_yyy()
	LOAD waiter->task;
	STORE waiter->task;
					Despertado por otro evento
	<preempt>
					Reanudar el procesamiento
					down_xxx() regresa
					llamada a foo()
					foo() estropea *waiter
	</preempt>
	LOAD waiter->list.next;
	--- OOPS ---

Esto podría solucionarse usando el bloqueo de semáforo, pero luego la
función down_xxx() tiene que obtener innecesariamente el spinlock
nuevamente, después de ser despertado el hilo.

La forma de lidiar con esto es insertar una barrera de memoria SMP general:

	LOAD waiter->list.next;
	LOAD waiter->task;
	smp_mb();
	STORE waiter->task;
	CALL wakeup
	RELEASE task

En este caso, la barrera garantiza que todos los accesos a memoria antes de
la barrera parecerán suceder antes de todos los accesos a memoria después
de dicha barrera con respecto a las demás CPU del sistema. _No_ garantiza
que todos los accesos a memoria antes de la barrera se completarán en el
momento en que la instrucción de la barrera en sí se complete.

En un sistema UP, donde esto no sería un problema, la función smp_mb() es
solo una barrera del compilador, asegurándose así de que el compilador
emita las instrucciones en el orden correcto sin realmente intervenir en la
CPU. Como solo hay un CPU, la lógica de orden de dependencias de esa CPU se
encargará de todo lo demás.


OPERACIONES ATÓMICAS
--------------------

Si bien son, técnicamente, consideraciones de interacción entre
procesadores, las operaciones atómicas se destacan especialmente porque
algunas de ellas implican barreras de memoria completa y algunas otras no,
pero se confía mucho en ellos en su conjunto a lo largo del kernel.

Consulte Documentation/atomic_t.txt para obtener más información.


ACCESO A DISPOSITIVOS
---------------------

Un driver puede ser interrumpido por su propia rutina de servicio de
interrupción y, por lo tanto, las dos partes del driver pueden interferir
con los intentos de controlar o acceder al dispositivo.

Esto puede aliviarse, al menos en parte, desactivando las interrupciones
locales (una forma de bloqueo), de modo que las operaciones críticas sean
todas contenidas dentro la sección de interrupción desactivada en el
controlador. Mientras la interrupción del driver está ejecutando la rutina,
es posible que el "core" del controlador no se ejecute en la misma CPU y no
se permita que su interrupción vuelva a ocurrir hasta que la interrupción
actual haya sido resuelta, por lo tanto, el controlador de interrupción no
necesita bloquearse contra esto.

Sin embargo, considere un driver que estaba hablando con una tarjeta
ethernet que tiene un registro de direcciones y un registro de datos. Si
el core de ese controlador habla con la tarjeta estando en desactivación de
interrupción y luego se invoca el controlador de interrupción del
controlador:

	IRQ LOCALES DESACTIVADAS
	writew(ADDR, 3);
	writew(DATA, y);
	IRQ LOCALES ACTIVADAS
	<interrupción>
	writew(ADDR, 4);
	q = readw(DATA);
	</interrupción>

El almacenamiento en el registro de datos puede ocurrir después del segundo
almacenamiento en el registro de direcciones si las reglas de orden son lo
suficientemente relajadas:

  	STORE *ADDR = 3, STORE *ADDR = 4, STORE *DATA = y, q = LOAD *DATA

Si se relajan las reglas de orden, se debe asumir que los accesos
realizados dentro de la sección con interrupción deshabilitada pueden
filtrarse fuera de esta y pueden intercalarse con accesos realizados en una
interrupción - y viceversa - a menos que se utilicenn barreras implícita o
explícitas.

Normalmente, esto no será un problema porque los accesos de E/S realizados
dentro de tales secciones incluirán operaciones de carga síncronas en
registros E/S estrictamente ordenados, que forman barreras de E/S
implícitas.


Una situación similar puede ocurrir entre una rutina de interrupción y dos
rutinas ejecutándose en separadas CPU que se comunican entre sí. Si tal
caso es probable, entonces se deben usar bloqueos de desactivación de
interrupciones para garantizar el orden.


=====================================
 Efectos de barrera de E/S del kernel
=====================================

La interfaz con periféricos a través de accesos de E/S es profundamente
específica para cada arquitectura y dispositivo. Por lo tanto, los drivers
que son inherentemente no portátiles pueden depender de comportamientos
específicos de sus sistemas de destino, con el fin de lograr la
sincronización de la manera más ligera posible. Para drivers que deseen ser
portátiles entre múltiples arquitecturas e implementaciones de bus, el
kernel ofrece una serie de funciones de acceso que proporcionan varios
grados de garantías de orden:

 (*) readX(), writeX():

	Las funciones de acceso MMIO readX() y writeX() usan un puntero al
	periférico al que se accede como un parámetro __iomem *. para punteros
	asignados los atributos de E/S predeterminados (por ejemplo, los
        devueltos por ioremap()), las garantías de orden son las siguientes:

	1. Se ordenan todos los accesos readX() y writeX() a un mismo periférico
	   entre estos. Esto asegura que los registros de acceso MMIO por el
	   mismo subproceso de la CPU a un dispositivo en particular llegarán en
	   el orden del programa.

	2. Se ordena un writeX() emitido por un subproceso de CPU que contiene un
	   spinlock antes de un writeX() al mismo periférico desde otro
           subproceso de CPU, si emitido después de una adquisición posterior del
	   mismo spinlock. Esto garantiza que ese registro MMIO escribe en un
           dispositivo en particular, mientras que se obtiene un spinlock en un
           orden consistente con las adquisiciones del cerrojo.

	3. Un writeX() por un subproceso de la CPU al periférico primero esperará
	   a la finalización de todas las escrituras anteriores en la memoria
           emitidas por, o bien propagadas por, el mismo subproceso. Esto asegura
	   que las escrituras de la CPU a un búfer DMA de salida asignadas por
           dma_alloc_coherent() serán visibles para un motor ("engine") DMA
           cuando la CPU escriba en sus registros de control MMIO, para activar
           la transferencia.

	4. Un readX() de un subproceso del CPU, desde el periférico, se
	   completará antes de que cualquier lectura subsiguiente de memoria por
	   el mismo subproceso pueda comenzar. Esto asegura que las lecturas de
           la CPU desde un búfer DMA entrantes asignadas por
           dma_alloc_coherent(), no verán datos obsoletos después de leer el
           registro de estado MMIO del motor DMA, para establecer que la
           transferencia DMA se haya completado.

	5. Un readX() por un subproceso del CPU, desde el periférico, se
	   completará antes de que cualquier bucle delay() subsiguiente pueda
           comenzar a ejecutarse en el mismo subproceso. Esto asegura que dos
           escrituras del CPU a registros MMIO en un periférico llegarán al menos
	   con 1us de diferencia, si la primera escritura se lee inmediatamente
           de vuelta con readX() y se llama a udelay(1) antes del segundo
           writeX():

		writel(42, DEVICE_REGISTER_0); // Llega al dispositivo ...
		readl(DEVICE_REGISTER_0);
		udelay(1);
		writel(42, DEVICE_REGISTER_1); // al menos 1us antes de esto....

Las propiedades de orden de los punteros __iomem obtenidos con valores de
atributos que no sean los valores por defecto (por ejemplo, los devueltos
por ioremap_wc()) son específicos de la arquitectura subyacente y, por lo
tanto, las garantías enumeradas anteriormente no pueden por lo general ser
aseguradas para accesos a este tipo de "mappings" (asignaciones).

 (*) readX_relaxed(), writeX_relaxed():

	Son similares a readX() y writeX(), pero proporcionan una garantía de
        orden de memoria más débil. Específicamente, no garantizan orden con
	respecto al bloqueo, los accesos normales a la memoria o los bucles
        delay() (es decir, los puntos 2-5 arriba) pero todavía se garantiza que
        se ordenarán con respecto a otros accesos desde el mismo hilo de la CPU,
        al mismo periférico, cuando se opera en punteros __iomem asignados con el
        valor predeterminado para los atributos de E/S.

 (*) readsX(), writesX():

	Los puntos de entrada readsX() y writesX() MMIO están diseñados para
        acceder FIFOs mapeados en memoria y basados en registros que residen en
        periféricos, que no son capaces de realizar DMA. Por tanto, sólo
        proporcionan garantías de orden readX_relaxed() y writeX_relaxed(), como
        se documentó anteriormente.

 (*) inX(), outX():

	Los puntos de entrada inX() y outX() están destinados a acceder a mapas
        de puertos "legacy" (antiguos) de periféricos de E/S, que pueden requerir
	instrucciones especiales en algunas arquitecturas (especialmente, en
        x86). El número de puerto del periférico que se está accedido se pasa
        como un argumento.

	Dado que muchas arquitecturas de CPU acceden finalmente a estos
        periféricos a través de un mapeo interno de memoria virtual, las
        garantías de orden portátiles proporcionadas por inX() y outX() son las
        mismas que las proporcionadas por readX() y writeX(), respectivamente, al
        acceder a una asignación con los valores de atributos de E/S
        predeterminados (los que haya por defecto).

        Los drivers de dispositivos pueden esperar que outX() emita una
        transacción de escritura no publicada, que espera una respuesta de
        finalización del periférico de E/S antes de regresar. Esto no está
        garantizado por todas las arquitecturas y por lo tanto no forma parte de
        la semántica de orden portátil.

 (*) insX(), outsX():

        Como arriba, los puntos de entrada insX() y outsX() proporcionan el mismo
        orden garantizado por readsX() y writesX() respectivamente, al acceder a
        un mapping con los atributos de E/S predeterminados.

 (*) ioreadX(), iowriteX():

        Estos funcionarán adecuadamente para el tipo de acceso que realmente están
        haciendo, ya sea inX()/outX() o readX()/writeX().

Con la excepción de los puntos de entrada (insX(), outsX(), readsX() y
writesX()), todo lo anterior supone que el periférico subyacente es
little-endian y, por lo tanto, realizará operaciones de intercambio de
bytes en arquitecturas big-endian.


===========================================
MODELO DE ORDEN MÍNIMO DE EJECUCIÓN ASUMIDO
===========================================

Debe suponerse que la CPU conceptual está débilmente ordenada, pero que
mantiene la apariencia de causalidad del programa con respecto a sí misma.
Algunas CPU (como i386 o x86_64) están más limitadas que otras (como
powerpc o frv), por lo que el caso más relajado (es decir, DEC Alpha) se
debe asumir fuera de código específico de arquitectura.

Esto significa que se debe considerar que la CPU ejecutará su flujo de
instrucciones en el orden que se quiera - o incluso en paralelo - siempre
que si una instrucción en el flujo depende de una instrucción anterior,
entonces dicha instrucción anterior debe ser lo suficientemente completa[*]
antes de que la posterior instrucción puede proceder; en otras palabras:
siempre que la apariencia de causalidad se mantenga.

 [*] Algunas instrucciones tienen más de un efecto, como cambiar el
     código de condición, cambio de registros o cambio de memoria - y
     distintas instrucciones pueden depender de diferentes efectos.

Una CPU puede también descartar cualquier secuencia de instrucciones que
termine sin tener efecto final. Por ejemplo, si dos instrucciones
adyacentes cargan un valor inmediato en el mismo registro, la primera puede
descartarse.


De manera similar, se debe suponer que el compilador podría reordenar la
corriente de instrucciones de la manera que crea conveniente, nuevamente
siempre que la apariencia de causalidad se mantenga.


=====================================
EFECTOS DE LA MEMORIA CACHÉ DE LA CPU
=====================================

La forma en que se perciben las operaciones de memoria caché en todo el
sistema se ve afectada, hasta cierto punto, por los cachés que se
encuentran entre las CPU y la memoria, y por el sistema de coherencia en
memoria que mantiene la consistencia de estado en el sistema.

En cuanto a la forma en que una CPU interactúa con otra parte del sistema a
través del caché, el sistema de memoria tiene que incluir los cachés de la
CPU y barreras de memoria, que en su mayor parte actúan en la interfaz
entre la CPU y su caché (las barreras de memoria lógicamente actúan sobre
la línea de puntos en el siguiente diagrama):

	    <--- CPU --->         :       <----------- Memoria ----------->
	                          :
	+--------+    +--------+  :   +--------+    +-----------+
	|  Core  |    | Cola   |  :   | Cache  |    |           |    +---------+
	|  CPU   |    | de     |  :   | CPU    |    |           |    |         |
	|        |--->| acceso |----->|        |<-->|           |    |         |
	|        |    | a      |  :   |        |    |           |--->| Memoria |
	|        |    | memoria|  :   |        |    |           |    |         |
	+--------+    +--------+  :   +--------+    | Mecanismo |    |         |
	                          :                 | de        |    +---------+
	                          :                 | Coherencia|
	                          :                 | de la     |    +--------+
	+--------+    +--------+  :   +--------+    | cache     |    |	      |
	|  Core  |    | Cola   |  :   | Cache  |    |           |    |        |
	|  CPU   |    | de     |  :   | CPU    |    |           |--->| Dispos |
	|        |--->| acceso |----->|        |<-->|           |    | itivo  |
	|        |    | a      |  :   |        |    |           |    |        |
	|        |    | memoria|  :   |        |    |           |    +--------+
	+--------+    +--------+  :   +--------+    +-----------+
	                          :
	                          :

Aunque es posible que una carga o store en particular no aparezca fuera de
la CPU que lo emitió, ya que puede haber sido satisfecha dentro del propio
caché de la CPU, seguirá pareciendo como si el acceso total a la memoria
hubiera tenido lugar para las otras CPUs, ya que los mecanismos de
coherencia de caché migrarán la cacheline sobre la CPU que accede y se
propagarán los efectos en caso de conflicto.

El núcleo de la CPU puede ejecutar instrucciones en el orden que considere
adecuado, siempre que parezca mantenerse la causalidad esperada del
programa. Algunas de las instrucciones generan operaciones de carga y
almacenamiento que luego van a la cola de accesos a memoria a realizar. El
núcleo puede colocarlos en la cola en cualquier orden que desee, y
continuar su ejecución hasta que se vea obligado a esperar que una
instrucción sea completada.

De lo que se ocupan las barreras de la memoria es de controlar el orden en
que los accesos cruzan, desde el lado de la CPU, hasta el lado de memoria,
y el orden en que los otros observadores perciben los efectos en el sistema
que sucedan por esto.

[!] Las barreras de memoria _no_ son necesarias dentro de una CPU
determinada, ya que las CPU siempre ven sus propias cargas y stores como si
hubieran sucedido en el orden del programa.

[!] Los accesos a MMIO u otros dispositivos pueden pasar por alto el
sistema de caché. Esto depende de las propiedades de la ventana de memoria
a través de la cual se accede a los dispositivos y/o el uso de
instrucciones especiales de comunicación con dispositivo que pueda tener la
CPU.


COHERENCIA DE CACHÉ FRENTE A DMA
---------------------------------

No todos los sistemas mantienen coherencia de caché con respecto a los
dispositivos que realizan DMA. En tales casos, un dispositivo que intente
DMA puede obtener datos obsoletos de la RAM, porque las líneas de caché
"sucias" pueden residir en los cachés de varias CPU, y es posible que no
se hayan vuelto a escribir en la RAM todavía. Para hacer frente a esto, la
parte apropiada del kernel debe vaciar los bits superpuestos de caché en
cada CPU (y tal vez también invalidarlos).

Además, los datos enviados por DMA a RAM, por un dispositivo, pueden ser
sobrescritos por líneas de caché sucias que se escriben de nuevo en la RAM
desde el caché de una CPU, después de que el dispositivo haya puesto sus
propios datos, o las líneas de caché presentes en el caché de la CPU pueden
simplemente ocultar el hecho de que la memoria RAM se haya actualizado,
hasta el momento en que la caché se descarta de la memoria caché de la CPU
y se vuelve a cargar. Para hacer frente a esto, la parte apropiada del
kernel debe invalidar los bits superpuestos del caché en cada CPU.

Consulte Documentation/core-api/cachetlb.rst para obtener más información
sobre administración de la memoria caché.


COHERENCIA DE CACHÉ FRENTE A MMIO
---------------------------------

La E/S mapeada en memoria generalmente se lleva a cabo a través de
ubicaciones de memoria que forman parte de una ventana del espacio de
memoria de la CPU, que tiene diferentes propiedades asignadas que la
ventana habitual dirigida a RAM.

Entre dichas propiedades, suele existir el hecho de que tales accesos
eluden el almacenamiento en caché por completo e ir directamente a los
buses del dispositivo. Esto significa que los accesos MMIO pueden, en
efecto, superar los accesos a la memoria caché que se emitieron
anteriormente. Una barrera de memoria no es suficiente en tal caso, sino
que el caché debe ser vaciado entre la escritura de la memoria caché, y el
acceso MMIO, si los dos son de cualquier manera dependiente.


=======================
COSAS QUE HACEN LAS CPU
=======================

Un programador podría dar por sentado que la CPU realizará las operaciones
de memoria exactamente en el orden especificado, de modo que si a la CPU se
entrega, por ejemplo, el siguiente fragmento de código a ejecutar:

	a = READ_ONCE(*A);
	WRITE_ONCE(*B, b);
	c = READ_ONCE(*C);
	d = READ_ONCE(*D);
	WRITE_ONCE(*E, e);

esperarían entonces que la CPU complete la operación de memoria para cada
instrucción antes de pasar a la siguiente, lo que lleva a una definida
secuencia de operaciones vistas por observadores externos en el sistema:

  	LOAD *A, STORE *B, LOAD *C, LOAD *D, STORE *E.

La realidad es, por supuesto, mucho más intrincada. Para muchas CPU y
compiladores, la anterior suposición no se sostiene porque:

 (*) es más probable que las cargas deban completarse de inmediato para
     permitir progreso en la ejecución, mientras que los stores a menudo se
     pueden aplazar sin problema;

 (*) las cargas se pueden hacer especulativamente, y el resultado es
     descartado si resulta innecesario;

 (*) las cargas se pueden hacer de forma especulativa, lo que lleva a que
     se haya obtenido el resultado en el momento equivocado de la secuencia
     de eventos esperada;

 (*) el orden de los accesos a memoria se puede reorganizar para promover
     un mejor uso de los buses y cachés de la CPU;

 (*) las cargas y los stores se pueden combinar para mejorar el rendimiento
     cuando se habla con memoria o hardware de E/S, que puede realizar
     accesos por lotes a ubicaciones adyacentes, reduciendo así los costes
     de configuración de transacciones (la memoria y los dispositivos PCI
     pueden ambos pueden hacer esto); y

 (*) la caché de datos de la CPU puede afectar al orden, y mientras sus
     mecanismos de coherencia pueden aliviar esto, una vez que el store
     haya accedido al caché- no hay garantía de que la gestión de la
     coherencia se propague en orden a otras CPU.

Entonces, digamos que lo que otra CPU podría observar en el fragmento de
código anterior es:

	LOAD *A, ..., LOAD {*C,*D}, STORE *E, STORE *B

	(Donde "LOAD {*C,*D}" es una carga combinada)


Sin embargo, se garantiza que una CPU es autoconsistente: verá que sus
 _propios_ accesos parecen estar correctamente ordenados, sin necesidad de
barrera de memoria. Por ejemplo con el siguiente código:

	U = READ_ONCE(*A);
	WRITE_ONCE(*A, V);
	WRITE_ONCE(*A, W);
	X = READ_ONCE(*A);
	WRITE_ONCE(*A, Y);
	Z = READ_ONCE(*A);

y asumiendo que no hay intervención de una influencia externa, se puede
suponer que el resultado final se parecerá a:

	U == el valor original de *A
	X == W
	Z == Y
	*A == Y

El código anterior puede hacer que la CPU genere la secuencia completa de
accesos de memoria:

	U=LOAD *A, STORE *A=V, STORE *A=W, X=LOAD *A, STORE *A=Y, Z=LOAD *A

en ese orden, pero, sin intervención, la secuencia puede contener casi
cualquier combinación de elementos combinados o descartados, siempre que la
perspectiva del programa del mundo siga siendo consistente. Tenga en cuenta
que READ_ONCE() y WRITE_ONCE() -no- son opcionales en el ejemplo anterior,
ya que hay arquitecturas donde una CPU determinada podría reordenar cargas
sucesivas en la misma ubicación. En tales arquitecturas, READ_ONCE() y
WRITE_ONCE() hacen lo que sea necesario para evitar esto, por ejemplo, en
Itanium los casts volátiles utilizados por READ_ONCE() y WRITE_ONCE() hacen
que GCC emita las instrucciones especiales ld.acq y st.rel
(respectivamente) que impiden dicha reordenación.

El compilador también puede combinar, descartar o diferir elementos de la
secuencia antes incluso de que la CPU los vea.

Por ejemplo:

	*A = V;
	*A = W;

puede reducirse a:

	*A = W;

ya que, sin una barrera de escritura o WRITE_ONCE(), puede que se asuma
que el efecto del almacenamiento de V a *A se pierde. Similarmente:

  	*A = Y;
  	Z = *A;

puede, sin una barrera de memoria o un READ_ONCE() y WRITE_ONCE(), esto
sea reducido a:

  	*A = Y;
  	Z = Y;

y la operación LOAD nunca aparezca fuera de la CPU.


Y LUEGO ESTÁ EL ALFA
--------------------

La CPU DEC Alpha es una de las CPU más relajadas que existen. No solo eso,
algunas versiones de la CPU Alpha tienen un caché de datos dividido, lo que
les permite tener dos líneas de caché relacionadas semánticamente,
actualizadas en momentos separados. Aquí es donde la barrera de dependencia
de dirección realmente se vuelve necesaria, ya que se sincronizan ambos
cachés con el sistema de coherencia de memoria, lo que hace que parezca un
cambio en el puntero, frente a que los nuevos datos se produzcan en el
orden correcto.

Alpha define el modelo de memoria del kernel Linux, aunque a partir de
v4.15, la adición al kernel de Linux de smp_mb() a READ_ONCE() en Alpha
redujo en gran medida su impacto en el modelo de memoria.


GUESTS DE MÁQUINAS VIRTUALES
-----------------------------

Los "guests" (invitados) que se ejecutan en máquinas virtuales pueden verse
afectados por los efectos de SMP incluso si el "host" (huésped) en sí se
compila sin compatibilidad con SMP. Este es un efecto de la interacción con
un host SMP mientras ejecuta un kernel UP. El uso obligatorio de barreras
para este caso de uso sería posible, pero a menudo no son óptimas.

Para hacer frente a este caso de manera óptima, están disponibles macros de
bajo nivel virt_mb() etc. Estas tienen el mismo efecto que smp_mb(), etc.
cuando SMP está habilitado, pero generan código idéntico para sistemas SMP
y no SMP. Por ejemplo, los invitados de máquinas virtuales debería usar
virt_mb() en lugar de smp_mb() al sincronizar contra un (posiblemente SMP)
anfitrión.

Estos son equivalentes a sus contrapartes smp_mb() etc. en todos los demás
aspectos, en particular, no controlan los efectos MMIO: para controlar los
efectos MMIO, utilice barreras obligatorias.


================
EJEMPLOS DE USOS
================

BUFFERS CIRCULARES
------------------

Las barreras de memoria se pueden utilizar para implementar almacenamiento
en búfer circular, sin necesidad de un cerrojo para serializar al productor
con el consumidor. Vea:

	Documentation/core-api/circular-buffers.rst

para más detalles.


===========
REFERENCIAS
===========

Alpha AXP Architecture Reference Manual, Segunda Edición (por Sites & Witek,
Digital Press)
	Capítulo 5.2: Physical Address Space Characteristics
	Capítulo 5.4: Caches and Write Buffers
	Capítulo 5.5: Data Sharing
	Capítulo 5.6: Read/Write Ordering

AMD64 Architecture Programmer's Manual Volumen 2: System Programming
	Capítulo 7.1: Memory-Access Ordering
	Capítulo 7.4: Buffering and Combining Memory Writes

ARM Architecture Reference Manual (ARMv8, for ARMv8-A architecture profile)
	Capítulo B2: The AArch64 Application Level Memory Model

IA-32 Intel Architecture Software Developer's Manual, Volumen 3:
System Programming Guide
	Capítulo 7.1: Locked Atomic Operations
	Capítulo 7.2: Memory Ordering
	Capítulo 7.4: Serializing Instructions

The SPARC Architecture Manual, Version 9
	Capítulo 8: Memory Models
	Appendix D: Formal Specification of the Memory Models
	Appendix J: Programming with the Memory Models

Storage in the PowerPC (por Stone and Fitzgerald)

UltraSPARC Programmer Reference Manual
	Capítulo 5: Memory Accesses and Cacheability
	Capítulo 15: Sparc-V9 Memory Models

UltraSPARC III Cu User's Manual
	Capítulo 9: Memory Models

UltraSPARC IIIi Processor User's Manual
	Capítulo 8: Memory Models

UltraSPARC Architecture 2005
	Capítulo 9: Memory
	Appendix D: Formal Specifications of the Memory Models

UltraSPARC T1 Supplement to the UltraSPARC Architecture 2005
	Capítulo 8: Memory Models
	Appendix F: Caches and Cache Coherency

Solaris Internals, Core Kernel Architecture, p63-68:
	Capítulo 3.3: Hardware Considerations for Locks and
			Synchronization

Unix Systems for Modern Architectures, Symmetric Multiprocessing and Caching
for Kernel Programmers:
	Capítulo 13: Other Memory Models

Intel Itanium Architecture Software Developer's Manual: Volumen 1:
	Sección 2.6: Speculation
	Sección 4.4: Memory Access