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

Add sendable RwLock guards #284

Open
djc opened this issue May 17, 2021 · 4 comments
Open

Add sendable RwLock guards #284

djc opened this issue May 17, 2021 · 4 comments

Comments

@djc
Copy link

djc commented May 17, 2021

I'm using parking_lot's RwLock in some graph-like code where I use rayon to parallelize initialization of the graph. To enforce some ordering, I'm taking a write lock when I initialize a node inside the rayon loop. Unfortunately, this means the locking happens with non-deterministic ordering, and some of the early nodes start writing edges to the neighboring nodes before those get locked.

Unfortunately, the RwLockWriteGuard is not Send, so I cannot easily bring it along inside the rayon loop. However, I noticed that there is an unsafe fn force_unlock_write(&self) method. Would it make sense to add a safe wrapper that adds a Send wrapper type which uses the forget()/force_unlock_write() pattern internally?

@Amanieu
Copy link
Owner

Amanieu commented May 17, 2021

If you enable the send_guard feature in cargo then the guards will implement Send (but it prevents the use of the deadlock detector).

@djc
Copy link
Author

djc commented May 17, 2021

Thanks! Might be useful to mention that somewhere in the documentation.

@Amanieu
Copy link
Owner

Amanieu commented May 17, 2021

It is mentioned in the README.

@djc
Copy link
Author

djc commented May 17, 2021

I find that many crates mention a list of feature flags in the top-level page of the reference documentation, for example tokio or opentelemetry.

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

No branches or pull requests

2 participants