lockfree
slice_deque
Our great sponsors
lockfree | slice_deque | |
---|---|---|
11 | 2 | |
695 | 150 | |
- | - | |
7.9 | 0.0 | |
20 days ago | over 2 years ago | |
C++ | Rust | |
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.
lockfree
- A lock-free ring-buffer with contiguous reservations (2019)
-
Atomics and Concurrency
If you're interested about lock-free data structures, I wrote [lockfree](https://github.com/DNedic/lockfree) a collection of lock-free data structures meant to be readable and both hosted system and embedded friendly.
-
Optimizing a Ring Buffer for Throughput
If you want more than a spsc queue, I've written `lockfree`, a collection of SPSC and MPMC data structures along the same principles the author here used:https://github.com/DNedic/lockfree.
The library is written in standard C++11 (but additional API's for higher C++ versions have been added), uses no dynamic allocation and is configurable so it is both big metal and deeply embedded friendly.
-
A collection of lock-free data structures written in standard C++11
- A lot of code won't work for types with no default constructors, but that is at least compile error
- Using memcpy[0] for arbitrary types is just wrong, see [1]
[0] https://github.com/DNedic/lockfree/blob/main/lockfree/inc/bi...
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p11...
-
Lock-free data structures
My friend wrote a few lock-free data structures and he is now looking for some feedback. Here is the link: https://github.com/DNedic/lockfree
- A collection of lock-free data structures written in standard c++11
- A collection of embedded friendly lock-free data structures written in standard C++11
slice_deque
-
A lock-free ring-buffer with contiguous reservations (2019)
> It's not an attack on the wording, but the correctness of your first bullet point. `unsafe` is appropriate for the initialization of a ring buffer in Rust. That's true for using `mmap` or anything in "pure" Rust using the allocator API to get the most idiomatic representation (which can't be done in safe or stable Rust). It's not one line. It's also not platform dependent, the code is the same on MacOS, Linux, and Windows the last I tried it.
We're not talking about the same thing then.
I'm talking about this code here: <https://github.com/gnzlbg/slice_deque/tree/master/src/mirror...> It is absolutely platform specific.
Yes, most ring buffer implementations feature a little bit of `unsafe` code. No, it doesn't make sense to say "I have a tiny amount of `unsafe` already, so adding more has no cost."
> But if your bottleneck is determined by the frequency at which channels get created or how many exist then I would call architecture into the question. ... This last month I've written a lock-free ring buffer to solve a problem and there's exactly one in an application that spawns millions of concurrent tasks.
Okay, but a lot of applications or libraries are written to support many connections, and you don't necessarily know when writing the code (or even when your server receives them) if those connections will be just cycled very quickly or will be high-throughput long-lived affairs. Each of those probably has a send buffer and a receive buffer. So while it might make sense for your application to have a single ring buffer for its life, applications which churn through them heavily are completely valid.
-
Go is about to get a whole lot faster
There is a single contiguous memory allocation, which mirrors itself.
One thread produces elements and pushes them at the tail (e.g. I/O bytes, in batch), and one thread consumes as many elements as possible in batch from the other end (e.g. all bytes available, in batch).
The mirror is required to allow processing all elements in the deque as if they were adjacent in memory.
This is the library i am using, the array contains an explanation : https://github.com/gnzlbg/slice_deque
What are some alternatives?
rc_event_queue - VecDeque-like fast, unbounded, mpmc/spmc concurent FIFO message queue. Lockless reads, write-lock writes.
distortos - object-oriented C++ RTOS for microcontrollers
glibc - GNU Libc
micro-gl - Headers Only C++11 CPU Vector Graphics. no std-lib, no FPU and no GPU required !
tlaplus - TLC is a model checker for specifications written in TLA+. The TLA+Toolbox is an IDE for TLA+.
Ring-Buffer - A simple ring buffer (circular buffer) designed for embedded systems.
set-ethernet-max-ring-buffer - Set max TX/RX ring buffer for ethernet device
jemalloc
bounded-spsc-queue - A Bounded SPSC queue for Rust
multiversion-concurrency-control - Implementation of multiversion concurrency control, Raft, Left Right concurrency Hashmaps and a multi consumer multi producer Ringbuffer, concurrent and parallel load-balanced loops, parallel actors implementation in Main.java, Actor2.java and a parallel interpreter
multiversion-concurrency-contro