A Common Lisp implementation of the CTrie, a lock-free concurrent key/value map with efficient snapshots and memory management.
CL-CTRIE is a Common Lisp implementation of the CTrie, a non-blocking concurrent hash array mapped trie for key/value storage. It solves the problem of scalable, lock-free concurrent access in shared-memory systems, offering efficient memory usage and atomic snapshots. The project provides a high-performance alternative to traditional concurrent hash tables with better insertion scalability and memory management.
Common Lisp developers building high-concurrency applications, such as servers, real-time systems, or any software requiring scalable, thread-safe key/value storage without locking overhead.
Developers choose CL-CTRIE for its lock-free concurrency, efficient O(1) snapshots, and memory-conscious design. It offers superior scalability for insertions compared to many concurrent hash tables and provides a functional, idiomatic Common Lisp API that integrates seamlessly into Lisp workflows.
lock-free, concurrent, key/value index with efficient memory-mapped persistence and fast transient storage models
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Supports concurrent LOOKUP, INSERT, and REMOVE operations without global locks, enabling high scalability in shared-memory systems as per the README's emphasis on non-blocking design.
Provides O(1) snapshot operations for consistent point-in-time views, enabling lock-free iterators, size retrieval, and clear operations without blocking concurrent access.
Allocated memory scales with the number of keys, avoiding the bloat common in other concurrent hash tables that don't shrink after removals, as highlighted in the README overview.
Offers a 'lispy' interface with mapping operators like CTRIE-DO and CTRIE-MAP, and DEFINE-CTRIE for functional decomposition, making it idiomatic for Common Lisp developers.
Only supports SBCL version 1.0.55+ on x86/x86-64, with no built-in support for other Common Lisp implementations or architectures, restricting its usability.
The project's last significant activity appears to be around 2012, with no recent updates, raising concerns about long-term support and compatibility with modern systems.
The README admits deviations from the original verified algorithm for a more functional style, increasing the risk of subtle bugs in lock-free code, which is notoriously difficult to debug.