2 ms·
> 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
by johnisgood 1y 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 1y 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.
- johnisgood 1y agoSo, what are the solutions if they are indeed not safe to do read / write concurrently? Like okay, I read "both []byte slices, which are not safe for concurrent r/w access", but then, what is the solution? If the claim is indeed true.
- sapiogram 1y agoSome options: - Make sure no one mutates the slice ever, making it safe to read - Guarding the slice behind a mutex, requiring anyone who reads or writes it to lock the mutex first - Using some kind of thread-safe slice implementation
- sirgallo 1y agoI went with option 1. On a mutation, I do a complete node copy where I also copy the key/value slices. When I set a child node for the first time or update a child, I create a branch new leaf node with a copy of the key/value. This way previous nodes maintain the original copy.