why is i++ not thread safe on a single core machine? [duplicate]

Answer 1

If the processor does not have a single instruction that can increment the contents of a memory location, the compiler would have to do something like generating:

 load      location, registerA
 increment registerA
 store     registerA, location

So even if any single instruction is atomic, the sequence is not. And even if there is a single

increment location

instruction there is no guarantee a compiler would use it. For example, the compiler might have done some optimizing and is using a register to hold some frequently-used value, only storing it back to memory at times mandated by any sequencing rules in the compiler's language's memory model.

Answer 2

The sequence of the instructions executed from 2 threads on a single core cannot be predicted. The following is a possible sequence, when both threads attempt to do i++, but the effect is equivalent to doing i++ once:

load i        # thread 1
system interrupt
load i        # thread 2, now i++ in thread 1 is not complete
increment i   # thread 2
store i       # thread 2
system interrupt
increment i   # thread 1, actually the same value
store i

Answer 3

What stops the system from descheduling one thread between the time it read the value and the time it wrote the value? Sure, it is less likely to happen, but on standard operating systems the kernel could get an interrupt at any time and decide that the other thread deserves to run. At that point, both threads would have read the same value and both will increment identically. However, the second thread could run for another time slice, incrementing thousands of times, and then when the first thread gets rescheduled, would zap all of the forward progress by the second thread by writing the stale value.

Answer 4

Consider the instructions that might be generated for a statement like i++. Of course this will depend upon your architecture/instruction set, but it will probably be something along the lines of:

LOAD    @i, r0    ;load the value of 'i' into a register from memory
ADD     r0, 1     ;increment the value in the register
STORE   r0, @i    ;write the updated value back to memory

Now consider how multithreading would be implemented in an operating-system, regardless of how many cores the machine has. At the most basic level, the OS is going to need some facility to interrupt the execution of the current thread, save its state, and perform a context switch to a different thread. The OS has no automatic way of knowing which instructions inside of a user thread should be treated as an atomic operation, and has the ability to initiate a context switch between any two instructions.

So what happens if the OS performs a context switch from one thread to the other between LOAD and ADD? Let's say that i started out with a value of 0, so r0 will be set to 0 when the first thread gets swapped out. The OS will save this value as part of that thread's state. Now the second thread runs, and performs the same LOAD statement. The value in memory is still 0, so r0 gets 0 loaded into it again. The thread increments the value and writes it back to memory, setting the value of i to 1. Now the first thread resumes execution, and the operating-system restores the value of r0 to 0 as part of its context switch. The first thread now performs its increment, setting r0 to 1, and the value of 1 gets stored in i again. Now the value of i is incorrect because two increments have been applied, but the value has only increased by 1.

So in a nutshell, even though i++ is a single statement in a high-level language, it generates multiple assembly-language instructions, and those instructions will not be treated as atomic by the operating-system/runtime environment unless you add extra synchronization logic around them.

Answer 5

Your question is tagged assembler but asks about i++. You have no guarantee that an i++ in your C code will compile to a single instruction that changes memory. If you have multiple threads that load i from memory with one instruction, increments it with another and writes it back to memory with a third, a thread switch between the first and third of those can cause some updates to i to be lost.

Answer 6

i++ has three operations:

• Fetch i into a register
• Increment the register
• Write it back to i

In between these operations, the thread might be interrupted by the scheduler so that a different thread can run (and modify i).