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

Ordering question #551

Closed
jjpe opened this issue Mar 8, 2018 · 3 comments
Closed

Ordering question #551

jjpe opened this issue Mar 8, 2018 · 3 comments
Labels

Comments

@jjpe
Copy link

jjpe commented Mar 8, 2018

I was just wondering: Do the Rayon parallel iterators preserve ordering?
For example, if I have vec![obj1, obj2, obj3].par_iter().map(|o| { operation_on(o) }), can I assume that the resulting iterator has the corresponding map results in the same order as in the vec!?

@cuviper
Copy link
Member

cuviper commented Mar 8, 2018

Yes. Your operation_on will be called in parallel, out of order, but if you have something like collect after that, it will still store the results in the original order.

@jjpe
Copy link
Author

jjpe commented Mar 9, 2018

That's awesome, thanks!

@KarelPeeters
Copy link

KarelPeeters commented Jul 18, 2021

For people coming here from google and ending up very confused (like me), this is not a universal guarantee, not everything in rayon is order-preserving, for example par_bridge does not preserve it.

See #669 or the the ParallelBridge docs.

thomaseizinger added a commit to itchysats/itchysats that referenced this issue Apr 27, 2022
It is really important that we feed the events in chronological order to
the aggregate. Previously, this was done implicitly through the insertion
order in the DB.

Rayon will preserve ordering [0] of the original iterator but given how
important this ordering is for our logic to work correctly, it is better
to be explicit about it.

[0]: rayon-rs/rayon#551
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants