4 ms·
As the comment you reply to states: “INC/DEC don’t give you a copy of the value to examine. (…) If you want that, you need a second instruction.” Here’s what y
by codeflo 4y ago
As the comment you reply to states: “INC/DEC don’t give you a copy of the value to examine. (…) If you want that, you need a second instruction.”
Here’s what you might be missing: Even on a single processor machine, if you have multiple threads and a preemptive (!) multitasking OS like Windows 95, any locking protocol can be interrupted mid-sequence. A second OS thread (yes, they existed) may be scheduled and observe an inconsistent state. Or it may perform an update on its own and leave the first state in an inconsistent state when it resumes.
And yes, this kind of stuff actually happened.
- YZF 4y agoI wrote that sort of code on those sorts of platforms ;) The bigger problem was code that assumed INC/DEC was atomic and broke when the first multi core CPUs came out. Everyone knows/knew that a sequence of instructions can be interrupted with multiple OS threads and preemption. So I don't think I'm missing that. INC/DEC give you flags but they don't give you a copy of the value. But you still need to LOCK INC or LOCK DEC for your code to be multi-core safe. And if you're sharing values you need something like "test and set" or a kernel synchronization object. EDIT: I was basically saying the comment above that was correct because the comment I was replying to seemed to suggest it wasn't. But I guess both of them are correct and we're all in agreement ;) EDIT2: So really I agree that InterlockedIncrement/Decerement were designed for multi-processing use case since they basically offer no advantage for a single core over just inc/dec (++/--) this is what the comment above the one I was replying to (gp?) was implying and the person responding to that seemed to think otherwise ;) but I think we still found out we all agree.