Friday, February 26, 2016

Introduction to Memory Barriers


The memory barrier instructions halt execution of the application code until a memory write of an instruction has finished executing. They are used to ensure that a critical section of code has been completed before continuing execution of the application code.

Memory accesses are randomly performed by CPU, however this could be a problem when multiple CPUs or I/O are accessing the same memory. The one way is to create a critical section using spinlocks or mutex or semaphore however this approach has its more overheads.

Linux can use its memory barriers to give a sort of security to memory via aligned or ordered access to the RAM. The random accesses to memory by CPU becomes more problematic in case of a Multi-core system. Memory barriers are only required where there's a possibility of interaction between two CPUs or between a CPU and a device( Refer the Abstract Memory Access Model as below). If it can be guaranteed that there won't be any such interaction in any particular piece of code, then memory barriers are not required. 

Memory barriers impose a perceived partial ordering over the memory operations on either side of the barrier.Such enforcement is important because the CPUs and other devices in a system can use a variety of tricks to improve performance, including reordering, deferral and combination of memory operations; speculative loads; speculative branch prediction and various types of caching. Memory barriers are used to override or suppress these tricks, allowing the code to sanely control the interaction of multiple CPUs and/or devices.


                                                      Abstract Memory Access Model 

It is important to note here that Memory Barriers are not suitable for bit fields. As compilers often modify the bit field code to non-atomic read/write code. Hence accessing to bit fields cannot be synchronized.

Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock.  If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one
field to corrupt the value of an adjacent field.





No comments:

Post a Comment