SPSCQueue.h
junction
SPSCQueue.h | junction | |
---|---|---|
1 | 1 | |
829 | 1,365 | |
- | - | |
4.6 | 0.0 | |
4 months ago | over 3 years ago | |
C++ | C++ | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
SPSCQueue.h
-
Notes on Concurrency Bugs
A triple buffer is a good choice if all you want is polling the latest data at any given time, and you want to avoid mutexes altogether. If you want each piece of data to be delivered exactly once, you can use a queue (bounded or "unlimited" though the latter doesn't supply backpressure which I hear causes problems). SPSC lock-free bounded queues are dead simple to write, and can be tuned for higher throughput even with contention (https://github.com/rigtorp/SPSCQueue claims to be nice, and I haven't had issues working with it aside from having to peek and pop separately, but it's C++, and not a misuse-proof API since it doesn't use the "handles" idea I talked about, and you can push/read/pop from the wrong thread). If you want the reader to poll/WaitForMultipleObjects until the queue has items, that has to be done separately from the SPSC.
And mutexes make a lot of things easier... and introduces "oops wrong mutex!" (Rust solves it) and deadlock (Rust doesn't solve it).
junction
-
Experiences with Concurrent Hash Map Libraries
junction has a very impressive performance benchmark here. Initially it worked for my application, but I ran into some issues: Only raw pointers are supported as either keys or values. This means I am responsible for memory management and it was a pain. junction's required dependency "turf" causes linker errors when compiling with -fsanitize=address because there are symbol name collisions. Every thread that accesses the hash map must periodically call an update function or memory will be leaked. No commits in over three years, GitHub issues aren't getting any attention. The author said it's experimental and he doesn't want it to become more popular
What are some alternatives?
moodycamel - A fast multi-producer, multi-consumer lock-free concurrent queue for C++11
HPX - The C++ Standard Library for Parallelism and Concurrency
libcds - A C++ library of Concurrent Data Structures
libdill - Structured concurrency in C
VexCL - VexCL is a C++ vector expression template library for OpenCL/CUDA/OpenMP
parallel-hashmap - A family of header-only, very fast and memory-friendly hashmap and btree containers.
Taskflow - A General-purpose Parallel and Heterogeneous Task Programming System
Thrust - [ARCHIVED] The C++ parallel algorithms library. See https://github.com/NVIDIA/cccl
moderngpu - Patterns and behaviors for GPU computing