3 ms·
"> Each quadrant is safe, except the one in the top right: shared mutable state. No. Your database is one giant shared mutable state. How is using a database
by astine 7y ago
"> Each quadrant is safe, except the one in the top right: shared mutable state.
No. Your database is one giant shared mutable state.
How is using a database safe then? Transactions."
Transactions are less an occasion where shared mutable state is made 'safe' during concurrency and more a situation where concurrent processes are forced to temporarily interact and operate in a sequential, non-concurrent, manner. They use locks under the covers. Databases manage to be parallel because different processes operate on different sets of data at the same time; they lock when two or more processes attempt to access the same row on a table. Transactional state access is still vulnerable to deadlocks and other difficulties of concurrent programming. This means that transactional state is not 'safe' in the same way that immutable and non-shared state are safe. It's just a much easier way of managing the kind of difficulties you have with shared mutable state than say, raw locks.
- kccqzy 7y agoNo. Please read about MVCC: https://en.m.wikipedia.org/wiki/Multiversion_concurrency_control https://en.m.wikipedia.org/wiki/Multiversion_concurrency_con... The tl;dr is that > Locks are known to create contention especially between long read transactions and update transactions. MVCC aims at solving the problem by keeping multiple copies of each data item. In this way, each user connected to the database sees a snapshot of the database at a particular instant in time. Any changes made by a writer will not be seen by other users of the database until the changes have been completed (or, in database terms: until the transaction has been committed.) In other words, the system uses immutable state under the hood plus some atomics/locking to present the abstraction of safe shared mutable state.
- deleted 7y ago[deleted]