1 / 10

Understanding Memory Barriers: Application in Processor Instructions

Learn about memory barriers, used to order read and write operations. Explore their importance in different programming languages and processors, and understand how to avoid memory latency issues caused by reordering operations.

leanna
Download Presentation

Understanding Memory Barriers: Application in Processor Instructions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Memory Barriers Dennis Byrnedennisbyrne@apache.org

  2. Defining the Problem Object connection = null; boolean initialized = false; // thread 1 writes twice // thread 2 reads twice connection = new Connection(); if(initialized) initialized = true; connection.use(); NullPointerException ?

  3. Root Cause: Memory Latency • Processors work hard to avoid memory latency • memory operations (reads & writes) are re-ordered • This is not a problem when … • data is local and/or immutable • there is only single processor • People do this also …

  4. Introduction Memory barriers, or fences, are a set of processor instructions used to apply ordering limitations on read and write operations.

  5. Visibility is “kind of” important • The Java Memory Model • Erlang send operators • Retlang and Jetlang Channels • C++ atomics • Scala Actors • Every semaphore, mutex, or atomic operation

  6. Consecutive Volatile Writes on Itanium 2 1 adds r37=592,r36;; ;...0b284149 0421 • st4.rel [r37]=r39 ;...00389560 2380 • adds r36=596,r36;; ;...84112544 4 st1.rel [r36]=r0 ;...09000048 a011 5 mf ;...00000044 0000 6 nop.i 0x0;; ;...00040000 7 mov r12=r33 ;...00600042 0021 8 mov.ret b0=r35,0x2000000001de81e0 The other side of the protocol ….

  7. Consecutive Volatile Reads on Itanium 2 1 adds r37=597,r36;; ;...84112554 2 ld1.acq r38=[r37];; ;...0b30014a a010 3 nop.m 0x0 ;...00000002 00c0 4 sxt1 r38=r38;; ;...00513004 5 cmp4.eq p0,p6=0,r38 ;...1100004c 8639 6 nop.i 0x0 ;...00000002 0003 7 br.cond.dpnt.many 0x2000000001de8220;; One side of the protocol ….

  8. Implicit Memory Barriers mov 0x160(%edi),%edi ;...8bbf6001 0000 mov %ecx,%edi ;...8bf9 add $0x8,%edi ;...83c708 lock cmpxchg %esi,(%edi) ;...f00fb137 mov $0x1,%eax ;...b8010000 00 Atomic CAS operation on x86 lock cmpxchg serializes pending memory operations

  9. Avoiding Memory Barriers Atomic CAS on a VMWare image with one processor: add $0x8,%edi ;...83c708 cmpxchg %esi,(%edi) ;...0fb137 mov $0x1,%eax ;...b8010000 00 Consecutive volatile reads in Java on SPARC: ld [ %l1 + 0x150 ], %i0 ;...f0046150 sethi %hi(0xff3fc000), %l0 ;...213fcff0 ld [ %l0 ], %g0 ;...c0042000 ret ;...81c7e008

  10. Memory Barriers Thanks Dennis Byrne – DRW Trading dennisbyrne@apache.org

More Related