Remove large amounts of unsafe from Refs via 'detached' lock guards #323
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(stacked on top of #322)
I came up with this novel abstraction for reducing the dependencies on pointers within dashmap. We need to hold the lock guard for the shard.
Since Ref/Mut wants to get proper reference values eventually, it doesn't matter whether you convert pointers early or later. It seems to work all the same.
Thus, we can convert
into
Since the detached guard does not own the data, it's inherently unsafe, but from my understanding and from asking others, it is still sound as long as the data is still coupled with the guard.
Ref
/Entry
APIs still hold the guard, which upholds this invariant.As a by-product of using this in mapref::multiple, I noticed that the RwLock guard is marked as GuardNotSend, meanwhile every iterator/ref is manually marked as Send/Sync. This seemed redundant, so I've additionally made the guard Send and then removed all manual send/sync impls.