Implement thread safe interface for the OrderedMap #63
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.
This PR add a struct
SyncOrderedMap
which is basically a Thread safe wrapped toOrderedMap
As mentioned in this comment: #62 (comment)
I understand implementing thread safe operation directly in the
OrderedMap
isn't what we want as it would add an extra complexity to scenarios where thread safe isn't required, adding another structSyncOrderedMap
give the consumer the choice to use or not the thread safe feature.I assumed that methods such as
GetElement
and the iterators are not really compatible with thread safe given that it will provide access to the inner component of theOrderedMap
which could then be used a non thread safe manner.Example we could totally return a
*Element
safely but using this Element to read/write the key or the value would kind of "corrupt" theSyncOrderedMap
For the same reason I didn't support
NewOrderedMapWithElements
forSyncOrderedMap
, however I think a method onOrderedMap
or another constructor forSyncOrderedMap
which would create a newSyncOrderedMap
from an existingOrderedMap
could be interesting, this would need to copy the value though, as we don't want values to be still accessible from a non thread safeOrderedMap
.Test:
I added a unit test verifying that the
SyncOrderedMap
is race condition free, not sure if it's enough for you?I think we could reimplement some of the test for this new struct to make sure it doesn't introduce any regression?
Question:
Should I also put my changes on
v1
andv2
given that it doesn't introduce any breaking chance?@elliotchance
This change is