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
[master <] Introduce a reader writer spin lock #1187
Conversation
431b479
to
3f8a745
Compare
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.
Great job, I like it very much! Only thing which I don't like is the usage of [[likely]]. I think it is impossible to predict the workload and hence we could actually lose performance by using it.
@Josipmrden I used this to play a bit with it to understand exactly what is going on. Maybe you will find it useful, if not ignore |
3f8a745
to
e9cb9fe
Compare
70c64aa
to
3bd76ff
Compare
It is possible for multiple read only queries to be accessing the same squence of vertices/edges. The reader mode of the spin lock will ensure multiple threads can make progress at the same time.
3bd76ff
to
bfd420e
Compare
It is possible for multiple read only queries to be accessing the same sequence of vertices/edges. The reader mode of the spin lock will ensure multiple threads can make progress at the same time.
There are situations where multiple readonly queries in parallel are contended on the same vertex lock. Take for example a highly connected supernode which is repetitively used in result values and it needs encode it to a bolt value for sending to the client.
Since
SpinLock
can only be used exclusively, it causes unnecessary blocking.RWSpinLock
would allow shared reading.Before: you can see heavy use of
__pthread_spin_lock
After: in the same part of the profile the locks don't even appear, this is because of the
RWSpinLock
[master < Task] PR
To keep docs changelog up to date, one more thing to do:
closes #1189