8000 How to Implement Key-Value Storage Using `folly::ConcurrentSkipList`? · Issue #2417 · facebook/folly · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

How to Implement Key-Value Storage Using folly::ConcurrentSkipList? #2417

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

Open
InfiniteNightmare opened this issue Apr 18, 2025 · 0 comments

Comments

@InfiniteNightmare
Copy link

I'm trying to use folly::ConcurrentSkipList to implement a key-value store where each key maps to a single value, similar to std::map. However, the current implementation and documentation seem to focus on key-only usage (like std::set), and do not provide examples or guidance on how to store both key and value in the skip list.

From my understanding of folly::ConcurrentSkipList, it is designed for unique keys, like std::set, but I need to store both a key and its associated value. I am unsure how to modify the container or use an accessor to store and retrieve a key-value pair efficiently while ensuring the following:

  • Lock-free or highly efficient thread-safe operations (insert, update, delete, and retrieval).
  • Efficient handling of insertions, updates, deletions, and retrievals while maintaining the benefits of the skip list in terms of sorted access and concurrency.

Could you provide guidance on:

  • How to implement key-value pairs using folly::ConcurrentSkipList?
  • Best practices for handling operations (insert, update, delete, retrieve) while ensuring efficient thread-safe access?
  • Ensuring the implementation remains lock-free or at least minimizes locking to ensure high concurrency and scalability?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@InfiniteNightmare and others
0