C<\/a>, that this is what the code is translated into. Serious implications arise for race conditions and atomic operations.<\/p>\n2.1.2 Atomic Operations<\/p>\n
An operation is atomic if no other processor should interrupt it. Take for example the above assembly code to add one to a register. In the architecture, it may actually have a few different steps on the circuit. The operation may start by fetching the value of the memory from the stick of ram, then storing it in the cache or a register, and then finally writing back [12] \u2013 under the description for fetch-and-add though your micro-architecture may vary. Or depending on performance operations, it may keep that value in cache or in a register which is local to that process \u2013 try dumping the -O2 optimized assembly of incrementing a variable. The problem comes in if two processors try to do it at the same time. The two processors could at the same time copy the value of the memory address, add one, and store the same result back, resulting in the value only being incremented once. That is why we have a special set of instructions on modern systems called atomic operations. If an instruction is atomic, it makes sure that only one processor or thread performs any intermediate step at a time. With x86 this is done by the lock prefix [8, p. 1120]. lock add BYTE PTR [0x20], 1<\/p>\n
Why don\u2019t we do this for everything? It makes commands slower! If every time a computer does something it has to make sure that the other cores or processors aren\u2019t doing anything, it\u2019ll be much slower. Most of the time we differentiate these with special consideration. Meaning, we will tell you when we use something like this. Most of the time you can assume the instructions are unlocked.<\/p>\n
2.1.3 Caching<\/p>\n
Ah yes, Caching. One of computer science\u2019s greatest problems. Caching that we are referring is processor caching. If a particular address is already in the cache when reading or writing, the processor will perform the operation on the cache such as adding and update the actual memory later because updating memory is slow [9, Section 3.4]. If it isn\u2019t, the processor requests a chunk of memory from the memory chip and stores it in the cache, kicking out the least recently used page \u2013 this depends on caching policy, but Intel\u2019s does use this. This is done because the l3 processor cache is roughly three times faster to reach than the memory in terms of time [11, p. 22] though exact speeds will vary based on the clock speed and architecture. Naturally, this leads to problems because there are two different copies of the same value, in the cited paper this refers to an unshared line. This isn\u2019t a class about caching, know how this could impact your code. A short but non-complete list could be<\/p>\n
1. Race Conditions! If a value is stored in two different processor caches, then that value should be accessed by a single thread.<\/p>\n
2. Speed. With a cache, your program may look faster mysteriously. Just assume that reads and writes that either happened recently or are next to each other in memory are fast.<\/p>\n
3. Side effects. Every read or write effects the cache state. While most of the time this doesn\u2019t help or hurt, it is important to know. Check the Intel programmer guide on the lock prefix for more information.<\/p>\n","protected":false},"excerpt":{"rendered":"