lkml.org 
[lkml]   [2015]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectInconsistent description in memory-barrier.txt
Hi, Paul,


I noticed that in the control dependency section in
memory-barrier.txt, you mistakenly made an inconsistent
description:


On the description part:

641 It is tempting to try to enforce ordering on identical stores on both
642 branches of the "if" statement as follows:
643
644 q = READ_ONCE(a);
645 if (q) {
646 barrier();
647 WRITE_ONCE(b, p);
648 do_something();
649 } else {
650 barrier();
651 WRITE_ONCE(b, p);
652 do_something_else();
653 }
654
655 Unfortunately, current compilers will transform this as follows at high
656 optimization levels:
657
658 q = READ_ONCE(a);
659 barrier();
660 WRITE_ONCE(b, p); /* BUG: No ordering vs. load from a!!! */
661 if (q) {
662 /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
663 do_something();
664 } else {
665 /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
666 do_something_else();
667 }
668

This part is incorporated in commit 2456d2a617de ("memory-barriers: Fix
description of 2-legged-if-based control dependencies") on 2014-08-13.

However, on the summary part:

803 (*) If both legs of the "if" statement begin with identical stores
804 to the same variable, a barrier() statement is required at the
805 beginning of each leg of the "if" statement.


This part is incorporated in commit 9b2b3bf53124
("Documentation/memory-barriers.txt:
Need barriers() for some control dependencies"), on 2014-02-12.



I think you missed fixing the summary part?




Thanks,
Jianyu Zhan


\
 
 \ /
  Last update: 2015-12-22 08:01    [W:0.035 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site