rust-cv / header-vec

Allows one to store a header struct and a vector all inline in the same memory on the heap and share weak versions for minimizing random lookups in data structures
MIT License
5 stars 2 forks source link

Begin of atomic append facilities #10

Open cehteh opened 6 days ago

cehteh commented 6 days ago

this is WIP I am still fleshing out some things. posting this early that you can see my intentions. Everything is still in flux.

You proposed 2 types one for non atomic and one for atomic access. Actually I need to do this in one type because i have some hybrid access. A non shared Vec can be mutated with &mut self, a shared Vec can be appended by a single thread from &self. When a &mut self is not available then .len() doing Relaxed ordering. This would be racy vs another thread that appends to the Vec but always memory safe when the append follows the contracts (only once thread append, length must be set after appending data). Clone does acquire semantic, since clone is already a expensive operation the cost is negligible and its the correct way when the atomic append is used.

A push_atomic/push_atomic_slice comes next.

Note: no rush: i said i want to use this in cowstr but that transition is a bit down in my queue.

cehteh commented 5 days ago

so, I leave this now for review, probably for some weeks. This is still not completely finished, i will add a push_slice() and push_slice_atomic() method at least.

Whatever is finished is open for some bikeshedding about method names and whenever the atomic_append feature should be default or not. I don't have ARM hardware where it would make a measurable difference in performance. On x86 atomics are pretty free/nil and differences between with/without atomics are below the noise floor. Because of this I decided to include the atomic_append in default. Even in embedded the majority of platforms nowadays support atomics.

On my side there is no urge to merge this yet. If this needs to be finished ping me.

vadixidav commented 4 days ago

I see, so essentially len still has the same performance characteristics as the previous implementation? It looks like this still preserves the old behavior, just adding the new behavior for synchronization. I think we can stick to one type then. Thanks for the draft. I am looking forward to the final version being published and I can give a review then.

cehteh commented 10 hours ago

added reserve/reserve_exact/shrink_to/shrink_to_fit, reworked the resize_insert fn for that. The resize that can reservation of multiple elements is vital for adding slices efficiently (and i need it for other things). I see that i find time to add the slice things next when i find time.