doc.go 3.0 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677
  1. /*
  2. Package stm provides Software Transactional Memory operations for Go. This is
  3. an alternative to the standard way of writing concurrent code (channels and
  4. mutexes). STM makes it easy to perform arbitrarily complex operations in an
  5. atomic fashion. One of its primary advantages over traditional locking is that
  6. STM transactions are composable, whereas locking functions are not -- the
  7. composition will either deadlock or release the lock between functions (making
  8. it non-atomic).
  9. To begin, create an STM object that wraps the data you want to access
  10. concurrently.
  11. x := stm.NewVar[int](3)
  12. You can then use the Atomically method to atomically read and/or write the the
  13. data. This code atomically decrements x:
  14. stm.Atomically(func(tx *stm.Tx) {
  15. cur := x.Get(tx)
  16. x.Set(tx, cur-1)
  17. })
  18. An important part of STM transactions is retrying. At any point during the
  19. transaction, you can call tx.Retry(), which will abort the transaction, but
  20. not cancel it entirely. The call to Atomically will block until another call
  21. to Atomically finishes, at which point the transaction will be rerun.
  22. Specifically, one of the values read by the transaction (via tx.Get) must be
  23. updated before the transaction will be rerun. As an example, this code will
  24. try to decrement x, but will block as long as x is zero:
  25. stm.Atomically(func(tx *stm.Tx) {
  26. cur := x.Get(tx)
  27. if cur == 0 {
  28. tx.Retry()
  29. }
  30. x.Set(tx, cur-1)
  31. })
  32. Internally, tx.Retry simply calls panic(stm.Retry). Panicking with any other
  33. value will cancel the transaction; no values will be changed. However, it is
  34. the responsibility of the caller to catch such panics.
  35. Multiple transactions can be composed using Select. If the first transaction
  36. calls Retry, the next transaction will be run, and so on. If all of the
  37. transactions call Retry, the call will block and the entire selection will be
  38. retried. For example, this code implements the "decrement-if-nonzero"
  39. transaction above, but for two values. It will first try to decrement x, then
  40. y, and block if both values are zero.
  41. func dec(v *stm.Var[int]) {
  42. return func(tx *stm.Tx) {
  43. cur := v.Get(tx)
  44. if cur == 0 {
  45. tx.Retry()
  46. }
  47. v.Set(tx, cur-1)
  48. }
  49. }
  50. // Note that Select does not perform any work itself, but merely
  51. // returns a transaction function.
  52. stm.Atomically(stm.Select(dec(x), dec(y)))
  53. An important caveat: transactions must be idempotent (they should have the
  54. same effect every time they are invoked). This is because a transaction may be
  55. retried several times before successfully completing, meaning its side effects
  56. may execute more than once. This will almost certainly cause incorrect
  57. behavior. One common way to get around this is to build up a list of impure
  58. operations inside the transaction, and then perform them after the transaction
  59. completes.
  60. The stm API tries to mimic that of Haskell's Control.Concurrent.STM, but
  61. Haskell can enforce at compile time that STM variables are not modified outside
  62. the STM monad. This is not possible in Go, so be especially careful when using
  63. pointers in your STM code. Remember: modifying a pointer is a side effect!
  64. */
  65. package stm