Our great sponsors
-
multiversion-concurrency-control
Implementation of multiversion concurrency control, Raft, Left Right concurrency Hashmaps and a multi consumer multi producer Ringbuffer, concurrent and parallel load-balanced loops, parallel actors implementation in Main.java, Actor2.java and a parallel interpreter
Thank you for writing this.
I have worked on the same problem. It lead to me implementing multiversion concurrency control. Multiversion concurrency control allows thread safety avoiding locks except for internal data structures of the MVCC.
Multiple threads can read/write the same data but they'll never modify the exact same data due to the multiple versions.
https://github.com/samsquire/multiversion-concurrency-contro...
I also implemented the bank account example but I serialised the account transactions in ConcurrentWithdrawer.java - this solution doesn't use multiversion concurrency control.
My other solution BankAccounts2.java and BankAccounts3.java take different approaches.
The BankAccounts2.java has 1 thread out of 11 threads that synchronizes the bank accounts and performs the serialization of account balances. The other threads generate transactions.
BankAccounts3.java simply uses a lock.
The problem with the bank accounts problem is that I am yet to work out how to scale it. You could shard threads to serve a certain range of account numbers.
Or you can separate the current balance of each account across threads and if the receiving transaction is less than that balance, you don't need to read other threads to check.
-
Thank you for writing this.
I have worked on the same problem. It lead to me implementing multiversion concurrency control. Multiversion concurrency control allows thread safety avoiding locks except for internal data structures of the MVCC.
Multiple threads can read/write the same data but they'll never modify the exact same data due to the multiple versions.
https://github.com/samsquire/multiversion-concurrency-contro...
I also implemented the bank account example but I serialised the account transactions in ConcurrentWithdrawer.java - this solution doesn't use multiversion concurrency control.
My other solution BankAccounts2.java and BankAccounts3.java take different approaches.
The BankAccounts2.java has 1 thread out of 11 threads that synchronizes the bank accounts and performs the serialization of account balances. The other threads generate transactions.
BankAccounts3.java simply uses a lock.
The problem with the bank accounts problem is that I am yet to work out how to scale it. You could shard threads to serve a certain range of account numbers.
Or you can separate the current balance of each account across threads and if the receiving transaction is less than that balance, you don't need to read other threads to check.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
ponyc
Pony is an open-source, actor-model, capabilities-secure, high performance programming language
Are you sure that the project is dead? I see movement in the main repository and the last release dates to 9 days ago: https://github.com/ponylang/ponyc/releases/tag/0.52.1