6 ms·

I never would have guessed that what I take for granted to be a multi-threaded intrinsic actually existed long before x86 multi-threading was widespread. A qui

I never would have guessed that what I take for granted to be a multi-threaded intrinsic actually existed long before x86 multi-threading was widespread. A quick search shows potential dual 386 boards, I assume these instructions were to support those?

teaearlgraycold 4y ago
These instructions exist to support preemptive multitasking, not multi-processing. Your process can get suspended in the middle of non-atomic additions. Then you have a race condition.
- rootw0rm 4y ago
  that makes sense
- userbinator 4y ago
  On x86, inc/dec cannot be interrupted. The main use-case for these atomic inc/dec functions (and the associated LOCK prefix, which has been there since the 8086) is indeed for multiprocessing. x86 was designed to support multiprocessing from the beginning, although it was rarely used, mostly in systems outside the PC architecture.
  - anderskaseorg 4y ago
    INC/DEC don’t give you a copy of the value to examine (the Windows 98 behavior described in the article). If you want that, you need a second instruction and you need to worry about being interrupted.
    - YZF 4y ago
      The parent is correct. You don't need to worry about being interrupted. If you did no program would be correct in the presence of interrupts. The entire state of the processor can be saved and restored during an interrupt as if nothing has happened. LOCK is for multi-processing. EDIT: That said you do have to worry about being interrupted mid-sequence of instructions and data races but that's what critical sections are for. So INC or DEC (which increment/decrement and set flags) are perfectly safe under interrupts. If you have more a more complex sequence then you need a critical section. However they are not safe (without the LOCK) under multi-processing. EDIT2: also to clarify you're not interrupted mid-instruction. I.e. you can't observe the undelying read/modify/write through interrupts, only through a second core/processor.
      - anderskaseorg 4y ago
        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.
      - 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.
  - wyldfire 4y ago
    Were these ALU primitives or were they like "load, increment, store"?The latter could easily be non-atomic.
    - gpderetta 4y ago
      INC/DEC are internally decomposed into separate read-modify-write operations, but are still atomic with regards to interrupts; for multiprocessing you need the LOCK prefix, which in the past brute-force locked the memory bus, but these days make sure that the operations are scheduled in such a way that the core is guaranteed not to lose ownership of the cacheline.
  - StillBored 4y ago
    Right, many of the early (~1975) era microcomputers were bus backplane machines, where the CPU boards were just one of the "bus masters" and designed to cooperatively share the mostly passive backplane. (ex: ss-50, s-100). It was fairly common to attach z80's and the like as secondary co-processors, as well as allowing peripheral boards direct access to RAM/etc via DMA. So, while I'm not aware of anyone building a machine using multiple 8086's its was pretty common to put 8086's and z80's together in the same machine, nevermind the 8087 was effectively a second processor as well until it was integrated in the 80486 DX. Although looking at a few of the schematics on http://www.s100computers.com/index.html http://www.s100computers.com/index.html I don't see anyone actually using the 8086 #LOCK pin even if they are running the processor in max mode to gain the extra control lines for the S-100. Probably because few people were thinking about full _symetric_ Multi Processing, vs heterogeneous machines, which were fairly common. Z80 boards existed for a lot of machines (I had one for my apple II+), as did various other combinations.
hun3 4y ago
Probably DMA accesses

teaearlgraycold 4y ago

These instructions exist to support preemptive multitasking, not multi-processing. Your process can get suspended in the middle of non-atomic additions. Then you have a race condition.

rootw0rm 4y ago
that makes sense
userbinator 4y ago
On x86, inc/dec cannot be interrupted. The main use-case for these atomic inc/dec functions (and the associated LOCK prefix, which has been there since the 8086) is indeed for multiprocessing. x86 was designed to support multiprocessing from the beginning, although it was rarely used, mostly in systems outside the PC architecture.
- anderskaseorg 4y ago
  INC/DEC don’t give you a copy of the value to examine (the Windows 98 behavior described in the article). If you want that, you need a second instruction and you need to worry about being interrupted.
  - YZF 4y ago
    The parent is correct. You don't need to worry about being interrupted. If you did no program would be correct in the presence of interrupts. The entire state of the processor can be saved and restored during an interrupt as if nothing has happened. LOCK is for multi-processing. EDIT: That said you do have to worry about being interrupted mid-sequence of instructions and data races but that's what critical sections are for. So INC or DEC (which increment/decrement and set flags) are perfectly safe under interrupts. If you have more a more complex sequence then you need a critical section. However they are not safe (without the LOCK) under multi-processing. EDIT2: also to clarify you're not interrupted mid-instruction. I.e. you can't observe the undelying read/modify/write through interrupts, only through a second core/processor.
    - anderskaseorg 4y ago
      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.
    - 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.
- wyldfire 4y ago
  Were these ALU primitives or were they like "load, increment, store"?The latter could easily be non-atomic.
  - gpderetta 4y ago
    INC/DEC are internally decomposed into separate read-modify-write operations, but are still atomic with regards to interrupts; for multiprocessing you need the LOCK prefix, which in the past brute-force locked the memory bus, but these days make sure that the operations are scheduled in such a way that the core is guaranteed not to lose ownership of the cacheline.
- StillBored 4y ago
  Right, many of the early (~1975) era microcomputers were bus backplane machines, where the CPU boards were just one of the "bus masters" and designed to cooperatively share the mostly passive backplane. (ex: ss-50, s-100). It was fairly common to attach z80's and the like as secondary co-processors, as well as allowing peripheral boards direct access to RAM/etc via DMA. So, while I'm not aware of anyone building a machine using multiple 8086's its was pretty common to put 8086's and z80's together in the same machine, nevermind the 8087 was effectively a second processor as well until it was integrated in the 80486 DX. Although looking at a few of the schematics on http://www.s100computers.com/index.html http://www.s100computers.com/index.html I don't see anyone actually using the 8086 #LOCK pin even if they are running the processor in max mode to gain the extra control lines for the S-100. Probably because few people were thinking about full _symetric_ Multi Processing, vs heterogeneous machines, which were fairly common. Z80 boards existed for a lot of machines (I had one for my apple II+), as did various other combinations.

hun3 4y ago

Probably DMA accesses