Preemptive Multitasking
-
In a preemptive environment, does a single CPU instruction execute atomically, even if it uses more than one clock cycle? Or can an instruction be preempted during its second of, say, three clock cycles?
The difficult we do right away... ...the impossible takes slightly longer.
-
In a preemptive environment, does a single CPU instruction execute atomically, even if it uses more than one clock cycle? Or can an instruction be preempted during its second of, say, three clock cycles?
The difficult we do right away... ...the impossible takes slightly longer.
As far as I know it should execute completely to preempt. If the instruction can be halted in the middle of the process I am pretty sure it will need to be considered as not being executed at all (as the process of changing from one process to another will copy all the registers, including the stack pointer). So, even if at the hardware level it may be interrupter without completing, I am sure we will never see partial values lost (but I really believe the interrupt itself will only work at the next instruction).
-
In a preemptive environment, does a single CPU instruction execute atomically, even if it uses more than one clock cycle? Or can an instruction be preempted during its second of, say, three clock cycles?
The difficult we do right away... ...the impossible takes slightly longer.
I just searched and this link gives a good information: http://www.sltf.com/articles/pein/pein9505.htm[^] There is a part that says this: "Interrupt processing has some basic requirements from the CPU. Before it can respond to an interrupt, the processor must wait for an "interruptible" state in its processing. For example, if the processor's writing to memory, it must wait until the write is done before processing the interrupt." So, it will never interrupt in the middle of a instruction. The instruction itself is always atomic.
-
I just searched and this link gives a good information: http://www.sltf.com/articles/pein/pein9505.htm[^] There is a part that says this: "Interrupt processing has some basic requirements from the CPU. Before it can respond to an interrupt, the processor must wait for an "interruptible" state in its processing. For example, if the processor's writing to memory, it must wait until the write is done before processing the interrupt." So, it will never interrupt in the middle of a instruction. The instruction itself is always atomic.
Ah, I see. Thank you for that information. :thumbsup:
The difficult we do right away... ...the impossible takes slightly longer.
-
I just searched and this link gives a good information: http://www.sltf.com/articles/pein/pein9505.htm[^] There is a part that says this: "Interrupt processing has some basic requirements from the CPU. Before it can respond to an interrupt, the processor must wait for an "interruptible" state in its processing. For example, if the processor's writing to memory, it must wait until the write is done before processing the interrupt." So, it will never interrupt in the middle of a instruction. The instruction itself is always atomic.
Sorry for the late reply, but I had to chime in here: It is a common misunderstanding, unless an instruction is designed to be atomic (like x86 CMPXCHG or 680x0 TAS), an instruction can be interrupted mid-execution (e.g. INC [mem] can be interrupted after the read and before the write of the incremented value. This moment would be considered interruptible even tough the operation is not completed). If you need guaranteed atomic operation, you have to either use an instruction that is designed as atomic or you have to implement an access control mechanism that is based on these atomic operation around your non-atomic operations. Semaphores etc. are based on these guaranteed atomic operations to guard complex, i.e. non-atomic, operations. On a side note, this concept becomes even worse when executing with multiple CPUs or cores where several instructions are executing simultaneously and they can interfere with each other even without preemption. In this situation atomically-designed operations still guarantee atomic execution while others are becoming indeterministic as they are executed in parallel.
