This repo is completely unsound, code like [1] is pervasive and demonstrates a total misunderstanding of what guarantees are provided -- or, really, not provided -- by "atomic" reads of unsafe.Pointer values. Data races everywhere!
Not safe, do not pass go, do not collect $200, absolutely do not use.
Thank you for debunking it so I didn't have to. I don't think I've ever seen someone post a low-level/concurrent data structure in Go that wasn't wildly unsound, so I assumed this was too.
ecshafer 6 hours ago [-]
Go is made by Google. Do they not have someone writing an equivalent of Java.util.concurrent.ConcurrentHashMap?
sapiogram 6 hours ago [-]
They do, there's a concurrent hashmap in the standard library. It doesn't get posted here or on Reddit, though.
diagraphic 7 hours ago [-]
There are many good implementations.
kiitos 7 hours ago [-]
Be more specific? OK
---
CopyNode broken
`CopyNode` duplicates only the parent; every child pointer is still shared
Any later mutation (for example `setValue`) writes through those shared pointers, so readers and historical snapshots are modified concurrently -- invalid, data race, memory model violation
Calling it twice on the same index flips the bit back to 0. During branch-creation on insert and during delete, this function is invoked multiple times on the same index, clearing a bit that should remain set and leaving orphaned children.
---
Invalid assumptions re: interior pointers
Only the root pointer is read with `atomic.LoadPointer`. All deeper fields like `children[pos]`, `bitmap`, and the byte-slice keys/values, are accessed directly after a successful CAS. Readers therefore race with writers that mutate these fields in place -- race condition, memory model violation, etc.
If another goroutine has already swapped in a different copy of `curr` (and mutated it) the CAS still succeeds because the pointer value is unchanged, merging incompatible sub-tries and corrupting the data
---
Use-after-free in sync.Pool
On CAS failure the freshly built `nodeCopy` is immediately returned to a `sync.Pool` -- undefined behavior
cMap.pool.PutNode(nodeCopy) // may race with outstanding readers
Other goroutines still holding references to that node can now access a reclaimed object, oops.
---
K/V Aliasing
Keys and values (both []byte slices, which are not safe for concurrent r/w access) are stored by reference, a mistake:
n.setKey(key)
n.setValue(value)
If the caller mutates those slices later (or concurrently in another goroutine), data races ahoy
---
Reader panics, etc.
- `getRecursive` accesses `children[pos]` without bounds or nil checks, concurrent shrink can make `pos` invalid
- `GetIndex` allows a negative `shiftSize` once `level >= 7` with `chunkSize = 5`, producing nonsense indices and potential slice-out-of-bounds
johnisgood 7 hours ago [-]
> both []byte slices, which are not safe for concurrent r/w access
You must clone the slice on both write and read, right?
I get that cloning incurs a memory allocation and a copy operation, but this is the price for safety when concurrent access is possible or your data may be bodified outside your structure.
You could probably intern immutable keys, or avoid storing if keys already exist and are immutable, or use an object pool (like sync.Pool) to reduce allocations if this happens at scale. Anything else I am missing?
sapiogram 5 hours ago [-]
> You must clone the slice on both write and read, right?
I haven't looked at the code, but that doesn't make sense to me. If you can't read the slice safely, you also can't clone it safely.
sirgallo 2 days ago [-]
Performance comparisons are made against go sync.Map, with cmapv2 on par or sometimes exceeding is on different workloads. It is both lock-free and thread safe, using atomic operations. It also supports sharding out of the box. cmapv2 with 10m k/v pairs where keys and values are 64bytes was able to achieve 1.5m w/s and 3m r/s.
latchkey 10 hours ago [-]
I've been using this one for years, can you do comparisons against it?
Not safe, do not pass go, do not collect $200, absolutely do not use.
[1] https://github.com/sirgallo/cmapv2/blob/280e3017ae4ba212f6f8...
---
CopyNode broken
`CopyNode` duplicates only the parent; every child pointer is still shared
https://github.com/sirgallo/cmapv2/blob/main/node.go#L11-L17Any later mutation (for example `setValue`) writes through those shared pointers, so readers and historical snapshots are modified concurrently -- invalid, data race, memory model violation
---
Bitmap corruption
`SetBit` uses XOR rather than “set”:
https://github.com/sirgallo/cmapv2/blob/main/utils.go#L41-L4...Calling it twice on the same index flips the bit back to 0. During branch-creation on insert and during delete, this function is invoked multiple times on the same index, clearing a bit that should remain set and leaving orphaned children.
---
Invalid assumptions re: interior pointers
Only the root pointer is read with `atomic.LoadPointer`. All deeper fields like `children[pos]`, `bitmap`, and the byte-slice keys/values, are accessed directly after a successful CAS. Readers therefore race with writers that mutate these fields in place -- race condition, memory model violation, etc.
https://github.com/sirgallo/cmapv2/blob/main/operation.go#L5...---
All xxxRecursive functions rely on those invalid interior pointer assumptions
Sequence in `putRecursive` / `deleteRecursive` is
https://github.com/sirgallo/cmapv2/blob/main/operation.go#L1...If another goroutine has already swapped in a different copy of `curr` (and mutated it) the CAS still succeeds because the pointer value is unchanged, merging incompatible sub-tries and corrupting the data
---
Use-after-free in sync.Pool
On CAS failure the freshly built `nodeCopy` is immediately returned to a `sync.Pool` -- undefined behavior
https://github.com/sirgallo/cmapv2/blob/main/operation.go#L1...Other goroutines still holding references to that node can now access a reclaimed object, oops.
---
K/V Aliasing
Keys and values (both []byte slices, which are not safe for concurrent r/w access) are stored by reference, a mistake:
If the caller mutates those slices later (or concurrently in another goroutine), data races ahoy---
Reader panics, etc.
You must clone the slice on both write and read, right?
I get that cloning incurs a memory allocation and a copy operation, but this is the price for safety when concurrent access is possible or your data may be bodified outside your structure.
You could probably intern immutable keys, or avoid storing if keys already exist and are immutable, or use an object pool (like sync.Pool) to reduce allocations if this happens at scale. Anything else I am missing?
I haven't looked at the code, but that doesn't make sense to me. If you can't read the slice safely, you also can't clone it safely.
https://github.com/cornelk/hashmap