5 ms·

That's not quite true. The language spec can mandate that the -= be atomic (the X86 equivalent is mandating a LOCK).

by niggler 14y ago

masklinn 14y ago
Technically it'd have to mandate that []-= be atomic, there's a load from and a store to a k:v collection, not just from and to memory.
- acdha 14y ago
  > there's a load from and a store to a k:v collection That is itself a separate specification question: does simple array access trigger full load/store semantics or is it simply returning a reference?
  - masklinn 14y ago
    Note that it's not a "simple array" here it's an associative one, a map. And of course it's not just access, it's the retrieval of a reference to an immutable cell, you can't just alter it in place unless you are certain no other reference to the cell exists in the system.
    - acdha 14y ago
      > Note that it's not a "simple array" here it's an associative one, a map. And of course it's not just access, it's the retrieval of a reference to an immutable cell, you can't just alter it in place unless you are certain no other reference to the cell exists in the system. This still comes down the question of whether your language preferes references or values: a design decision in-scope for the original question. A language designer might quite reasonably choose to specify that `foo[i] -= 1` means “Get a reference to the object at position i in container foo and tell it to decrement”, in which case the container access is not a concurrency issue except for write / replacing the initial object. This approach can also be implemented atomically in many architectures because it's a simple arithmetic operation rather than retrieving and storing immutable objects. It would also potentially be easier to scale if threads don't typically update the same elements because you could perform locking at the cell level rather than the entire container.
zopticity 14y ago
Totally agreed. Why do I have to lock it myself (even on a high level language like Ruby)? I'm not programming for C!
- Someone 14y ago
  You only have to do it yourself once you decide to use threads. And there is not really a way around that. If the language mandated that all primitive operations (for whatever reasonable operation of 'primitive') were atomic, most multi-threaded programs would slow down to a crawl. Even ignoring that, having atomic primitives is not sufficient to prevent race conditions. Things like "if balance > withdrawal {balance -= withdrawal; ...} need larger ranges of locking, and no compiler is going to tell you how large they have to be.

That's not quite true. The language spec can mandate that the -= be atomic (the X86 equivalent is mandating a LOCK).

by niggler 14y ago

That's not quite true. The language spec can mandate that the -= be atomic (the X86 equivalent is mandating a LOCK).

Technically it'd have to mandate that []-= be atomic, there's a load from and a store to a k:v collection, not just from and to memory.

acdha 14y ago
> there's a load from and a store to a k:v collection That is itself a separate specification question: does simple array access trigger full load/store semantics or is it simply returning a reference?
- masklinn 14y ago
  Note that it's not a "simple array" here it's an associative one, a map. And of course it's not just access, it's the retrieval of a reference to an immutable cell, you can't just alter it in place unless you are certain no other reference to the cell exists in the system.
  - acdha 14y ago
    > Note that it's not a "simple array" here it's an associative one, a map. And of course it's not just access, it's the retrieval of a reference to an immutable cell, you can't just alter it in place unless you are certain no other reference to the cell exists in the system. This still comes down the question of whether your language preferes references or values: a design decision in-scope for the original question. A language designer might quite reasonably choose to specify that `foo[i] -= 1` means “Get a reference to the object at position i in container foo and tell it to decrement”, in which case the container access is not a concurrency issue except for write / replacing the initial object. This approach can also be implemented atomically in many architectures because it's a simple arithmetic operation rather than retrieving and storing immutable objects. It would also potentially be easier to scale if threads don't typically update the same elements because you could perform locking at the cell level rather than the entire container.

zopticity 14y ago

Totally agreed. Why do I have to lock it myself (even on a high level language like Ruby)? I'm not programming for C!

Someone 14y ago
You only have to do it yourself once you decide to use threads. And there is not really a way around that. If the language mandated that all primitive operations (for whatever reasonable operation of 'primitive') were atomic, most multi-threaded programs would slow down to a crawl. Even ignoring that, having atomic primitives is not sufficient to prevent race conditions. Things like "if balance > withdrawal {balance -= withdrawal; ...} need larger ranges of locking, and no compiler is going to tell you how large they have to be.