When I play around with multithreaded concurrent algorithms, I try solve a simulation of moving money between accounts in a thread safe way. It really is just deduct from one account and then add to another account.
If you don't use a mutex or a lockfree algorithm, you can end up with more money (money creation) or money destruction (money missing) when you transfer money between accounts and there is another transaction to the same account in a similar time frame. This is due to a race hazard where addition and subtraction are each individually 3 operations and if they interleave then they cause the writeback of an incorrect result and omission of another result:
This simulation has money creation, because the two transactions don't see eachother.
So I add the money up at the end of the simulation to see if it is equal to the money that the simulation started with.
When I say money sharding, I am not sharding by account. If an account has 12,000 in it, and I have 12 threads, each thread stores 1000. The fast path is a transaction goes to that thread and that thread handles the transaction if the amount of money being deducted is less than or equal to 1000. If the transaction amount is greater than what is available in one thread, then it has to be routed to other threads.
I never generate a transaction greater than what is available than all threads, so that part always works, for routing to accounts that have enough money.
An extremely slow path would have to transact a bit from multiple threads until the transaction is complete.
I've never worked on fintech or banking software, so I don't know how it works in practice but I did try implementing an order matching engine (which from my perspective is just a sort ascending + sort descending of participants bids or asks) I haven't worked on parallelising that yet.
If you don't use a mutex or a lockfree algorithm, you can end up with more money (money creation) or money destruction (money missing) when you transfer money between accounts and there is another transaction to the same account in a similar time frame. This is due to a race hazard where addition and subtraction are each individually 3 operations and if they interleave then they cause the writeback of an incorrect result and omission of another result:
This simulation has money creation, because the two transactions don't see eachother.So I add the money up at the end of the simulation to see if it is equal to the money that the simulation started with.
When I say money sharding, I am not sharding by account. If an account has 12,000 in it, and I have 12 threads, each thread stores 1000. The fast path is a transaction goes to that thread and that thread handles the transaction if the amount of money being deducted is less than or equal to 1000. If the transaction amount is greater than what is available in one thread, then it has to be routed to other threads.
I never generate a transaction greater than what is available than all threads, so that part always works, for routing to accounts that have enough money.
An extremely slow path would have to transact a bit from multiple threads until the transaction is complete.
I've never worked on fintech or banking software, so I don't know how it works in practice but I did try implementing an order matching engine (which from my perspective is just a sort ascending + sort descending of participants bids or asks) I haven't worked on parallelising that yet.