Editing Software transactional memory (section)

== Conceptual advantages and disadvantages ==
In addition to their performance benefits,{{citation needed|date=December 2017}} STM greatly simplifies conceptual understanding of multithreaded programs and helps make programs more maintainable by working in harmony with existing high-level abstractions such as objects and modules. Lock-based programming has a number of well-known problems that frequently arise in practice:

* Locking requires thinking about overlapping operations and partial operations in distantly separated and seemingly unrelated sections of code, a task which is very difficult and error-prone.
* Locking requires programmers to adopt a locking policy to prevent [[Deadlock (computer science)|deadlock]], [[livelock]], and other failures to make progress. Such policies are often informally enforced and fallible, and when these issues arise they are insidiously difficult to reproduce and debug.
* Locking can lead to [[priority inversion]], a phenomenon where a high-priority thread is forced to wait for a low-priority thread holding exclusive access to a resource that it needs.

In contrast, the concept of a memory transaction is much simpler, because each transaction can be viewed in isolation as a single-threaded computation. Deadlock and livelock are either prevented entirely or handled by an external transaction manager; the programmer need hardly worry about it. Priority inversion can still be an issue, but high-priority transactions can abort conflicting lower priority transactions that have not already committed.

However, the need to retry and abort transactions limits their behavior. Any operation performed within a transaction must be [[Idempotence|idempotent]] since a transaction might be retried. Additionally, if an operation has [[Side effect (computer science)|side effects]] that must be undone if the transaction is aborted, then a corresponding [[Rollback (data management)|rollback]] operation must be included. This makes many [[input/output]] (I/O) operations difficult or impossible to perform within transactions. Such limits are typically overcome in practice by creating buffers that queue up the irreversible operations and perform them after the transaction succeeds. In [[Haskell]], this limit is enforced at [[compile time]] by the [[type system]].