[HN Gopher] Where's the Race Condition? "works on AArch64, how c...
       ___________________________________________________________________
        
       Where's the Race Condition? "works on AArch64, how can it fail on
       x86_64?"
        
       Author : matt_d
       Score  : 9 points
       Date   : 2022-05-27 19:12 UTC (3 hours ago)
        
 (HTM) web link (cpufun.substack.com)
 (TXT) w3m dump (cpufun.substack.com)
        
       | josephcsible wrote:
       | tl;dr explanation of the bug: memory_order_acquire guarantees
       | that things won't be moved from after it to before it, and
       | memory_order_release guarantees that things won't be moved from
       | before it to after it. The buggy code was doing
       | atomicBase.store(nb, memory_order_release) followed by
       | atomicEnd.load(memory_order_acquire), and relied on the order of
       | those not being swapped, which is not guaranteed.
       | 
       | Since x86_64 has a strong memory model, that code just got
       | compiled into regular MOV instructions there. The Intel software
       | developer's manual says "The Intel-64 memory-ordering model
       | allows a load to be reordered with an earlier store to a
       | different location", and that's exactly what triggers the bug
       | there.
       | 
       | On AArch64, that code got compiled into STLR and LDAR
       | instructions, which can't be reordered in that way (see
       | https://stackoverflow.com/q/67397460/7509065 and
       | https://stackoverflow.com/q/65466840/7509065), so the bug didn't
       | show up there.
        
       ___________________________________________________________________
       (page generated 2022-05-27 23:01 UTC)