5 ms·

It's worth reading that excellent article alongside Glyph's excellent article from the opposite perspective: https://glyph.twistedmatrix.com/2014/02/unyielding.

It's worth reading that excellent article alongside Glyph's excellent article from the opposite perspective: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html A few languages avoid the pitfalls of threads, like Rust where its ownership system protects you.

anonymoushn 5y ago
This is a nice post. Off the top of my head, I can't think of any ways of avoiding this issue. Even Rust doesn't really avoid it because different requests could plausibly create their own representations of the payee and payer.
- laurencerowe 5y ago
  I think Rust avoids this issue because it limits you to a single mutable reference. So even if each thread constructed its own payee and payer, their underlying balances would still reference the same shared state so only one thread at a time would be allowed a mutable reference to payee and payer balances.
  - anonymoushn 5y ago
    It doesn't limit you to a single in-memory representation of each entry in a remote database.
    - IshKebab 5y ago
      You could probably do it for a key value store, but I think it would take a custom database to do it for a relational database.
    - laurencerowe 5y ago
      (The above comment was changed. When I replied it was talking about different threads reading from a database.) In that case you’d be relying on the database rather than the programming language to manage shared state. (The article is more about how to safely manage shared state within a process.)
    - laurencerowe 5y ago
      > It doesn't limit you to a single in-memory representation of each entry in a remote database. If you have a remote database then you likely have multiple processes at play. For safety in those cases you need to rely on transactional safety at the database level or if transactions are not available then you may want to use a tool like TLA+ to check your distributed algorithm.
      - anonymoushn 5y ago
        The example clearly has that though, otherwise it would not need yield from server.update_balances([payer, payee])

anonymoushn 5y ago

This is a nice post. Off the top of my head, I can't think of any ways of avoiding this issue. Even Rust doesn't really avoid it because different requests could plausibly create their own representations of the payee and payer.

laurencerowe 5y ago
I think Rust avoids this issue because it limits you to a single mutable reference. So even if each thread constructed its own payee and payer, their underlying balances would still reference the same shared state so only one thread at a time would be allowed a mutable reference to payee and payer balances.
- anonymoushn 5y ago
  It doesn't limit you to a single in-memory representation of each entry in a remote database.
  - IshKebab 5y ago
    You could probably do it for a key value store, but I think it would take a custom database to do it for a relational database.
  - laurencerowe 5y ago
    (The above comment was changed. When I replied it was talking about different threads reading from a database.) In that case you’d be relying on the database rather than the programming language to manage shared state. (The article is more about how to safely manage shared state within a process.)
  - laurencerowe 5y ago
    > It doesn't limit you to a single in-memory representation of each entry in a remote database. If you have a remote database then you likely have multiple processes at play. For safety in those cases you need to rely on transactional safety at the database level or if transactions are not available then you may want to use a tool like TLA+ to check your distributed algorithm.
    - anonymoushn 5y ago
      The example clearly has that though, otherwise it would not need yield from server.update_balances([payer, payee])