I have a question regarding the Windows version.

[orz--]

Will you continue supporting Windows XP?
If you can drop support for Windows XP, wouldn't changing the exclusive control from CriticalSection to Slim Reader/Writer Locks (SRWLs) improve performance?

[erthink]

Switching to SRWL will slightly reduce the cost of locks, but it will have a very minor impact on overall performance.

Actually libmdbx already has a substitute for SRWL used when running on Windows XP, but critical sections are still in use because ones provide deadlock detection/prevention (via native exceptions handling). Such detection is required to return an error code in case of invalid API usage, instead of a hard deadlock that looks like one or more processes are hanging somewhere inside libmdbx by an unknown reason.

It is possible to implement us own deadlock detection mechanism for using SRWL, but this will slightly increase overhead, which will reduce the benefits of using SRWL in comparison with critical sections. So it makes very little sense without abandoning the use of file locks, which are used in libmdbx to share a database file in Windows.

In turn, file locks are used to prevent unauthorized actions with the database file on the part of users. This decision was made about 10 years ago, based on the results of an analysis of a problematic case when the user had a centralized backup system:

• the user believed that if the backup was created without errors, then his data is saved, including the database managed by libmdbx;
• in fact, the database file was copied without synchronization with constantly committed transactions in several dozen libmdbx DB instances, as a result of which some of the copies were inconsistent and unusable;
• the user reinstalled the system on a new SSD, immediately destroying the data on the old one to avoid leaks, and then discovered that previously made backup copies of the database were wrong and unusable.

The documentation indicated and explained why copying should be done using the mdbx_copy or mdbx_dump utility, but it was still difficult to respond to the user's outrage: Why are obviously incorrect actions not prevented if there are all the means for this?. Thus I came to the conclusion that on Windows, due to the initial presence of mandatory file locks, there are generally accepted rules and expectations of both users and developers of backup systems. Therefore, it is necessary to prevent such situations, and accordingly use Windows file locking API.

Further, the cost of file locks contributes significantly only in scenarios where many small writing transactions are executed. But libmdbx is not targeted for such use cases, a current versions have high write amplification factor (due MVCC approach without WAL) and therefore do not show high performance. Most likely, even if we do away with file locks, writing data to storage media will become a next bottleneck in such scenarios.

Nonetheless, the mdbx_txn_checkpoint() function is available in current versions of libmdbx, which allows to get rid of the overhead of file locks and critical sections both, in extreme scenarios with continuous execution of many writing transactions.

[orz--]

Thank you for taking the time to explain the details.
I learned that in the case of Windows, there were other purposes besides mutual exclusion.

[erthink]

@orz--, my answer is quite long and detailed. I hope it becomes clear to you that the point is not to support older versions of Windows, but to reasonability of improvements while meet the expectations of database durability and foolproofing.