Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Hazard Pointer Reclamation - Unlock Tagged list faster #2106

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Hazard Pointer Reclamation - Unlock Tagged list faster #2106

wants to merge 1 commit into from

Commits on Sep 24, 2024

  1. Hazard Pointer Reclamation - Unlock Tagged list faster (facebook#2106) 

    Summary:
Pull Request resolved: facebook#2106

PROBLEM
During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for `tagged_`).
There is opportunity to improve the performance of reclamation, by keeping the `tagged_` list locked for a smaller amount of time.

SOLUTION
The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the `tagged_` list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort.
The locking of list is to guard against the `tagged_` list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed.
Also validated that the `nomatch` handling is thread-safe - The cohort's `push_safe_obj` uses as CAS loop to safely add to the top of the list.
Would multiple copies of an object be pushed into a cohort? No - An object is either in the retirement list (i.e. list) in the cohort, or it's been processed for reclamation. This guarantee already exists (the diff doesn't change that). This means the only way multiple copies of an object can be pushed back to the safe list is if we end up clearing the `tagged_` list within the domain - which is the synchronization / shared memory point. Since we do dequeue and enqueue of that list under a lock, an object should would never appear on that list. The only (shared object) change is around addition to the cohort's safe list, which is meant to be thread-safe.

Reviewed By: yfeldblum

Differential Revision: D51638674
    @facebook-github-bot
    Gaurav Mogre authored and facebook-github-bot committed Sep 24, 2024
    Configuration menu
    Copy the full SHA
    c588122 View commit details
    Browse the repository at this point in the history