@antiochp Please take review on this. I'm not sure whether the read is safe for us.

In case a WriteTransaction is ongoing, this read can continue execute, so in race condition we will get a DifficultyIter which is being updated.

Is this OK? since the next call will get the updated one.

OK. Now I feel like I have a better grasp of the "writes on multiple threads" behavior -

http://www.lmdb.tech/doc/index.html

The library is fully thread-aware and supports concurrent read/write access from multiple processes and threads. Data pages use a copy-on- write strategy so no active data pages are ever overwritten, which also provides resistance to corruption and eliminates the need of any special recovery procedures after a system crash. Writes are fully serialized; only one write transaction may be active at a time, which guarantees that writers can never deadlock. The database structure is multi-versioned so readers run with no locks; writers cannot block readers, and readers don't block writers.

Specifically -

Writes are fully serialized; only one write transaction may be active at a time, which guarantees that writers can never deadlock.

So there are two things we need to be aware of -

1. We cannot have multiple write transactions in a single thread (this will deadlock).
2. We can safely have multiple threads each with a write transaction (but this will block).

And those two are different, even though they can temporarily look similar to an outside observer.

Ugly but it works...

Fully agree! Hope you will give a READ ONLY batch for us to call, then it will be much more clean 😄

So there are two things we need to be aware of -

1. We cannot have multiple write transactions in a single thread (this will deadlock).
2. We can safely have multiple threads each with a write transaction (but this will block).

I want to add the 3rd thing which need to be remembered:
3. Readers run with no locks. Writers cannot block Readers, and Readers don't block Writers.