3 ms·
PDF at https://dl.acm.org/doi/pdf/10.1145/1454456.1454466?download=true https://dl.acm.org/doi/pdf/10.1145/1454456.1454466?download=...
by JonChesterfield 4y ago
PDF at https://dl.acm.org/doi/pdf/10.1145/1454456.1454466?download=true https://dl.acm.org/doi/pdf/10.1145/1454456.1454466?download=...
- int_19h 4y agoThis seems to be arguing that the main problem with STM is performance? I don't think that's a particularly convincing argument in this day and age, when we had plenty of experience with concurrency-induced bugs on one hand, and that much more compute power on the other. End-to-end ST could give all the same safety guarantees as e.g. Rust, but packaged in a mental model that is easier to teach and much, much easier to write code for. Even if it means, say, a 10x slowdown, I think that there are many use cases where this would be acceptable if it meant significant improvements in safety. The problem is the end-to-end part. You don't just need STM - ideally, you need everything that the code can do to be transactional, including any other system that it interacts with in a way that causes a state change. This isn't feasible, so in practice you have to restrict STM to a subset of code which does not perform operations that cannot be rolled back. But with any existing platform, it ends up being such a small subset that it's not worth the bother; and even if you disregarded backwards compatibility and designed something from scratch specifically for end-to-end ST, it would still be limited wrt networking.