Skip to content
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

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Conversation

cehteh
Copy link
Contributor

@cehteh cehteh commented Sep 17, 2024

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
Copy link
Contributor Author

cehteh commented Sep 17, 2024

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
Copy link
Member

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
Copy link
Contributor Author

cehteh commented Sep 23, 2024

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()
@cehteh
Copy link
Contributor Author

cehteh commented Sep 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants