Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com