3 ms·
But the concern with a shared integer is correctness under inc/dec. If you have a multi-processor and you don't LOCK then the value can be anything because it'
by YZF 4y ago
But the concern with a shared integer is correctness under inc/dec. If you have a multi-processor and you don't LOCK then the value can be anything because it's racy. With multiple threads there is still correctness when multiple threads access the atomic and the flags returned are correct without the need to "lock the bus". The article just explains why the return value uses the flags - for correctness. If you have a sequence of instructions then (potentially) you don't have correctness either with multiple threads on the same core or across cores.
EDIT: if your point was that you can't return the value using either LOCK INC or INC and either on a single core or multiple cores then your point is correct. I sort of read it as INC itself (the x86 instruction) is racy under multi-threading.
- anderskaseorg 4y agoThe context in which this discussion takes place is “Return Values: The function returns the resulting incremented value” and “Since Windows 98 was a uniprocessor operating system, it didn’t have to worry about a second processor changing the memory at the same time”. The concern with a shared integer in this context is that you get interrupted between INC and MOV.