-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Add
]: LevelDB Benchmarks
#3667
[Add
]: LevelDB Benchmarks
#3667
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is needed, Core and other programs/plugins use concurrent.
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 Adding lock here is to tell others that this can be used for concurrency, but it should not.
That's the user's bug, and we can't help them hide the bug. |
|
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? |
WRONG 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. |
5e9d5bf
to
685d19a
Compare
Optimization
]: remove unnecessary locks in Snapshot
implementationsOptimization
]: lock in LevelDB.Snapshot
Fine. |
Optimization
]: lock in LevelDB.SnapshotAdd
]: LevelDB Benchmarks
* master: (43 commits) Fix `GetAndChange` warnings (neo-project#3702) `Murmur3` should not be cryptographic hash algorithm (neo-project#3668) Test: add tests for native contract id (neo-project#3697) Update nugets (neo-project#3692) [Core P2P] fix the bug (neo-project#3695) Add hardfork HF_Echidna (neo-project#3454) Fix: add lock for RocksDbStore.Snapshot to keep same behavior as MemoryStore and LevelDbStore (neo-project#3689) Nullable rocks db (neo-project#3686) Nullable leveldb (neo-project#3685) Enforcement Compiler Warnings (neo-project#3687) [`Update`] Dotnet & Compiler Version (neo-project#3684) [`Add`]: LevelDB Benchmarks (neo-project#3667) [`Fix`]: Behavior when `keyPrefix` is null in different `IStore.Seek` impls. (neo-project#3682) Improve calculatenetworkfee (neo-project#3674) more 2025 (neo-project#3678) Nullable in Storage classes (neo-project#3670) readonly (neo-project#3676) [Fix] Set max entries for `VerifyProof` in `statePlugin` (neo-project#3675) Neo.json.benchmarks (neo-project#3673) Happy new year 2025 (neo-project#3677) ... # Conflicts: # src/Neo/Neo.csproj # src/Neo/ProtocolSettings.cs # src/Neo/SmartContract/ApplicationEngine.cs # src/Neo/SmartContract/Native/NeoToken.cs # src/Neo/SmartContract/Native/RoleManagement.cs # tests/Neo.UnitTests/SmartContract/Native/UT_NativeContract.cs
Description
In PR #3606,
LevelDbStore.Snapshot
introduces a lock to protect concurrent operations on theWriteBatch
.But:
LevelDbStore.Snapshot
has this synchronization mechanism, butRocksDbStore.Snapshot
doesn't.WriteBatch
s (LevelDB and RocksDB`) are not for concurrent operations. If there are concurrent operations, each thread should use its own WriteBatch.In summary, write operations on
Snapshot
should not be concurrent, so these locks are unnecessary.Fixes # (issue)
Type of change
Checklist: