Hacker News Reader

Comment by DeathArrow | Hacker News Reader

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.

View on HN

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

> 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

Account balance is necessarily a shared mutable state.

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.

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com