When working with high throughput concurrent code like consumer producer pipelines, it's better to avoid shared mutable state entirely. Something actor like fits better and C# or Go channels works wonders.

▲ internet_points 12 hours ago | parent | next [-]

TFA has a whole section praising actors for certain tasks and explaining why it doesn't fit here.

▲ mrkeen 12 hours ago | parent | prev | next [-]

> it's better to avoid shared mutable state entirely.

Yes! I would even go so far as to have the type system separate the mutable from the non-mutable for this reason!

> Something actor like fits better and C# or Go channels works wonders.

Or even STM channels/queues:

  https://hackage.haskell.org/package/stm/docs/Control-Concurrent-STM-TChan.html
  https://hackage.haskell.org/package/stm/docs/Control-Concurrent-STM-TQueue.html

▲ kreetx 13 hours ago | parent | prev | next [-]

Account balance is necessarily a shared mutable state.

▲

tlb 11 hours ago | parent [-]

It's not necessarily shared. You could assign a single thread to own the account balances, reading requests from a message queue. That probably scales better than locking. A single thread can do several million transactions per second, more than the entire global financial system.

▲

xmcqdpt2 9 hours ago | parent | next [-]

And in a green threading system like Go or Scala Cats, the balances thread isn’t a thread at all, and it will run in the same thread as the transfer caller when the call isn’t contended, so you don’t even have a context switch.

▲

kreetx 8 hours ago | parent | prev [-]

What if you want to compose an action on a balance with something else? (That is what the OP is about)

Also, with a queue, you've moved the shared state elsewhere, namely, into the queue.

▲

tlb 6 hours ago | parent [-]

The account-owning thread has to accept messages for every atomic action you need it to do.

There are lots of standard shared queues you can pick from that have been fully regression tested. That's almost always better than mixing concurrency in with your business logic.

	▲	kreetx 5 hours ago \| parent [-]
		Sure, but what I meant is when there is some other thing that needs to happen atomically together with the balance handled by that one thread (i.e, both balance and other thing change or neither do). You'll need another thread for that other thing, then a method to synchronize the two and.. you're back at the mutex.

▲ IshKebab 13 hours ago | parent | prev [-]

Sure, but sometimes shared mutable state is better, especially from a performance point of view. For example blurring an image.

	▲	janetpacker 13 hours ago \| parent [-]
		Isn't that a typical case where you don't have to share anything? Divide the image into N chunks, let N threads handle each one, no sharing, just need a single sync point at the end to wait on completion.