-
-
Notifications
You must be signed in to change notification settings - Fork 216
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
Implement freelist class #783
base: develop
Are you sure you want to change the base?
Conversation
🤖 Upon creation, pull request description does not have a link to an issue. If there is a related issue, please add it to the description using any of the supported formats. |
Hi, sorry for late reply, I was ill. Will take a look in upcoming days, thanks for the patch! |
Sorry again for delay. The patch looks great overall!
Yes, this is intended: lock-free structures typically support only a limited set of operations. In this case, only two: This is perfect for us, because we want to use free list as a cache for a slab pool. Using LIFO is preferred over FIFO here, because recently deallocated objects have a higher chance to of still being in the CPU cache.
Yes, lock-free operations usually have overhead, and using SEQ_CST everywhere only increases it. Personally, I try to avoid inventing my own lock-free algorithms, and if I have to, I stick with SEQ_CST everywhere, as I don't feel proficient enough in this topic. Hence, core::Atomic is SEQ_CST-only, to keep its usage in the codebase simpler. However, when we're implementing a well-known algorithm where the correct memory barriers were already carefully designed and reviewed by many eyeballs, using ACQ/REL is beneficial. So in this case, yes, it would be nice to use lower-level core::AtomicOps and replicate barriers from the article, just like we do in MpscQueue (which implements Dmitry Vyukov queue). With this approach, implementation of containers like MpscQueue and FreeList can be more complicated, but based on a reference code and thus verifiable. And our custom code that uses core::Atomic, MpscQueue, etc, can remain simpler and much easier to verify and review. Feedback on the code
|
Hey @gavv,
the PR is not ready yet (obvious lack of tests, still some work on the code) but I wanted to double check whether this goes in the direction you envisioned.
Especially regarding the very limited functionality of the
FreeList
.Another thing: Right now I use the default memory order coming from the
Atomic
templates (sequentially consistent ordering). This should work in principle, but deviates from what is suggested in the article you linked.To my understanding, using the stricter memory ordering might introduce some performance issues under heavy contention.
Since a more fine grained memory order control is possible with the
AtomicOps
, I was wondering what you think about this.#734