multiversion-concurrency-control VS hamt

The code is in this repository https://github.com/samsquire/multiversion-concurrency-control in MultiplexingThread.java and MultiplexProgramParser.java

https://github.com/samsquire/multiversion-concurrency-contro...

And I implemented a 3 way text diff with myers algorithm based on https://blog.jcoglan.com/2017/02/12/the-myers-diff-algorithm...

https://github.com/samsquire/text-diff

I implemented an eventually consistent mesh protocol that uses timestamps to provide last write wins

I think I lean towards per-thread sharding instead of mutex based or lock free data structures except for lockfree ringbuffers.

You can get embarassingly parallel performance if you split your data by thread and aggregate periodically.

If you need a consistent view of your entire set of data, that is slow path with sharding.

In my experiments with multithreaded software I simulate a bank where many bankaccounts are randomly withdrawn from and deposited to. https://github.com/samsquire/multiversion-concurrency-contro...

I get 700 million requests per second due to the sharding of money over accounts.

If you want some sample code to implement MVCC, I implemented MVCC in multithreaded Java as a toy example

https://github.com/samsquire/multiversion-concurrency-contro...

First read TransactionC.java then read MVCC.java

I wrote an unrolled switch statement in Java to simulate eager async/await across treads.

https://github.com/samsquire/multiversion-concurrency-contro...

The goal is that a compiler should generate this for you. This code is equivalent to the following:

   task1:

https://doc.rust-lang.org/book/ch16-00-concurrency.html

I've been working on implementing Java async/await state machine with switch statements and a scheduling loop. If the user doesn't await the async task handle, then the task's returnvalue is never handled. This is similar to the Go problem with the go statement.

https://github.com/samsquire/multiversion-concurrency-contro...

If your async call returns a handle and

yield value2++

https://github.com/samsquire/multiversion-concurrency-contro...

I am still working on allowing multiple coroutines to be in flight in parallel at the same time. At the moment the tasks share the same background thread.

I asked this stackoverflow question regarding C++ coroutines, as I wanted to use coroutines with a thread pool.

https://stackoverflow.com/questions/74520133/how-can-i-pass-...

This is very interesting. Thank you for submitting this and thank you for working on this.

I am highly interested in parallelism and high concurrency. I implemented multiversion concurrency control in Java.

https://github.com/samsquire/multiversion-concurrency-contro...

I am curious how to handle replication with high concurrency. I'm not sure how you detect dangerous reads+writes to the same key (tuples/fields) across different replica machines. In other words, multiple master.

I am aware Google uses truetime and some form of timestamp ordering and detection of interfering timestamps. But I'm not sure how to replicate that.

I began working on an algorithm to synchronize database records, do a sort, then a hash for each row where hash(row) = hash(previous_row.hash + row.data)

Then do a binary search on hashes matching/not matching. This is a synchronization algorithm I'm designing that requires minimal data transfer but multiple round trips.

The binary search would check the end of the data set for hash(replica_a.row[last]) == hash(replica_b.row[last]) then split the hash list in half and check the middle item, this shall tell you which row and which columns are different.

This isn't a very good explanation. The wikipedia article isn't great either. I like this description:

https://github.com/mkirchner/hamt#persistent-hash-array-mapp...

The name does tell you quite a bit about what these are:

* Hash - rather than directly using the keys to navigate the structure, the keys are hashed, and the hashes are used for navigation. This turns potentially long, poorly-distributed keys into short, well-distributed keys. However, that does mean you have to compute a hash on every access, and have to deal with hash collisions. The mkirchner implementation above calls collisions "hash exhaustion", and deals with them using some generational hashing scheme. I think i'd fall back to collision lists until that was conclusively proven to be too slow.

* Trie - the tree is navigated by indexing nodes using chunks of the (hash of the) key, rather than comparing the keys in the node

* Array mapped - sparse nodes are compressed, using a bitmap to indicate which logical slots are occupied, and then only storing those. The bitmaps live in the parent node, rather than the node itself, i think? Presumably helps with fetching.

A HAMT contains a lot of small nodes. If every entry is a bitmap plus a pointer, then it's two words, and if we use five-bit chunks, then each node can be up to 32 entries, but i would imagine the majority are small, so a typical node might be 64 bytes. I worry that doing a malloc for each one would end up with a lot of overhead. Are HAMTs often implemented with some more custom memory management? Can you allocate a big block and then carve it up?

Could you do a slightly relaxed HAMT where nodes are not always fully compact, but sized to the smallest suitable power of two entries? That might let you use some sort of buddy allocation scheme. It would also let you insert and delete without having to reallocate the node. Although i suppose you can already do that by mapping a few empty slots.