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.