-
Notifications
You must be signed in to change notification settings - Fork 2
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
Begin of atomic append facilities #10
base: main
Are you sure you want to change the base?
Conversation
This is a very early draft. method names and semantic may change.
…pare_capacity()' method
so, I leave this now for review, probably for some weeks. This is still not completely finished, i will add a 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. On my side there is no urge to merge this yet. If this needs to be finished ping me. |
I see, so essentially |
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. |
* introduces a helper union to fix simplify alignment calculations no need for cmp and phantom data anymore * add simple testcase that triggered the miri issue * change end_ptr_atomic_mut(), using the rewritten start_ptr()
So, this concludes my work for now. Eventually other std::Vec mehtods/Traits (like Extend) could be added. Currently i have no urgent need for those. Integration into cowstr is kindof later in the queue i'll see if i miss some things then. |
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.