3 ms·
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
by 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 agoIt doesn't limit you to a single in-memory representation of each entry in a remote database.
- IshKebab 5y agoYou 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 agoThe example clearly has that though, otherwise it would not need yield from server.update_balances([payer, payee])