10 ms·

It’s clear from the article and the chain of parent comments that we’re talking about threads with preemptive multitasking and access to a shared integer in mem

It’s clear from the article and the chain of parent comments that we’re talking about threads with preemptive multitasking and access to a shared integer in memory. I didn’t say INC/DEC are unsafe; I said they don’t satisfy the contract of the function in the article, the whole point of which is about the return value. If you (e.g.) combine an INC/DEC with a MOV to fetch the return value, that’s unsafe. You can make it safe with a critical section, but that may be unnecessarily inefficient. The XADD instruction referenced in the article, when it’s available (486+), can be used to satisfy the contract without this overhead.

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 ago
  The 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.

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 ago
The 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.