The 80386 processor did not support symmetric multiprocessing, yet we discussed atomic operations when in our overview of the processor. If the processor doesn’t even support symmetric multiprocessing, why does it matter? <\/p>\n
Well, one reason is that the 80386 processor does support asymmetric<\/i> multiprocessing. Floating point operations are performed by a coprocessor, and the main processor and coprocessor are both accessing the same memory. Another source of competing memory access is from hardware devices that are using Direct Memory Access (DMA). <\/p>\n
Even within the processor, you have to worry about races, because you might be racing with yourself<\/i>. <\/p>\n
The 80386 did not support symmetric multiprocessing, but it did support pre-emptive multitasking, which means that any multi-instruction sequence is at risk of being interrupted, and at the worst possible time. <\/p>\n
\n ; decrement the variable and check against zero\n mov eax, [var]\n dec eax\n mov [var], eax\n je zero\n<\/pre>\nIf the threads gets pre-empted between the first and third instructions, then the contents of the variable may be changed by another thread, and the decrement operation becomes non-atomic. To ensure atomicity, you need to force the compiler to generate a single
dec<\/code> instruction, and then to test the flags directly from the decrement. <\/p>\n\n ; decrement the variable and check against zero\n dec [var]\n jz zero\n<\/pre>\nThere was no way to express this level of detail to compilers of that era, so you had to hide it behind a function call. <\/p>\n