-
Notifications
You must be signed in to change notification settings - Fork 98
add ReadOnly mode and change IsoCopy behavior #40
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
base: master
Are you sure you want to change the base?
Conversation
|
To elaborate on this, the read-only mode is to avoid the mutation on the origin tree's |
| defer tr.unlock(!tr.readOnly) | ||
| } | ||
| if !tr.readOnly { | ||
| tr.isoid = newIsoID() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The read-only mode is mainly to avoid the mutation on this field, so that we can have a fully read-only tree instance but supports IsoCopy method at the same time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative approach is to simply add a new method IsoCopyReadOnly without adding a new mode, and make it callers's responsibility to avoid modify the origin tree in place. That'll make the PR less intrusive. WDYT?
Context
I'm experimenting with the optimistic concurrency control pattern using the
IsoCopyfeature, it should be useful in read-heavy scenarios, this patch is some necessary changes to enable this pattern.The performance difference of different concurrency control strategies differs a lot based on the workload, for my local testing scenario, the CAS is faster than
Mutexin some cases, but slower in some other extreme cases, but both are much faster thanRWMutex.