For me it's ok, but I think that @Jim8y think the opposite

How is everything always ok? Let me refresh your mind! The reason for this is, core does or any other program that called this library, plugins included. This protects us from concurrent operations. Because WriteBatch can't be called concurrently. Its not supported, by leveldb!

The core issue here is 3, we should not have concurrent operations, indeed, but how could we detect or avoid issue if concurrent operation is mistakenly involved, maybe by third party lib, maybe by some other modules? Say few years later it's no longer us to maintain this repo, how could 'they' avoid making such mistakes unintentionally. Many hidden design I faced while maintaining the core, 'oh you should not do it this way, it's wrong, but you won't know it until the project crashes.

The core issue here is 3, we should not have concurrent operations, indeed, but how could we detect or avoid issue if concurrent operation is mistakenly involved, maybe by third party lib, maybe by some other modules? Say few years later it's no longer us to maintain this repo, how could 'they' avoid making such mistakes unintentionally. Many hidden design I faced while maintaining the core, 'oh you should not do it this way, it's wrong, but you won't know it until the project crashes.

Using a WriteBatch in a concurrent context is a misuse(therefore, the WriteBatch in LevelDB and RocksDB does not need to be concurrency safe).

Adding lock here is to tell others that this can be used for concurrency, but it should not.
We can't provide a wrong way to use it.

how could 'they' avoid making such mistakes unintentionally.

That's the user's bug, and we can't help them hide the bug.

This is needed, Core and other programs/plugins use concurrent.

1. No concurrent use in Core;
2. WriteBatch is used for a single thread to commit a transaction with multi Put or Delete operations. We shouldn't support a wrong way of using it.

Yes, using it in concurrent is wrong and misuse, exactly and very clear, but the problem is how could you detect misuse and prevent it being misused. Require solid understanding with the core code/structure and thirdparty code/structure right? Say we have 100 details need to care about that will allow you to do it, but is actually wrong, what's worse it will casue problem that is hard to debug and trace, is the project still maintainable?

Using a WriteBatch in a concurrent context is a misuse(therefore, the WriteBatch in LevelDB and RocksDB does not need to be concurrency safe).

WRONG
However other objects (like Iterator and WriteBatch) may require external synchronization. If two threads share such an object, they must protect access to it using their own locking protocol. More details are available in the public header files.

Reference: https://github.com/google/leveldb/blob/main/doc/index.md#concurrency

Plus this is your safe way to prevent such use. Nothing stops a SDK user or 3rd-party plugin or plugins in general from using different threads.

Fine.
Now this PR is to improve the lock operations, and add comments and benchmarks.