3 ms·

It seems like a lot of these data structs are not thread safe. Other than ck_bitmap which seems to be read/write thread safe, ck_array, ck_hs, ck_ht, and parts

by reza_n 11y ago

It seems like a lot of these data structs are not thread safe. Other than ck_bitmap which seems to be read/write thread safe, ck_array, ck_hs, ck_ht, and parts of ck_ring only allow a single writer in the presence of many readers. Did I misread something here? Still a lot of good stuff here, but not sure if these data structures can be used without external locking.

alexforster 11y ago
They're mostly all some combination of lock-free/wait-free single-producer multi-consumer datastructures, meaning one thread can produce some data (think, an epoll/kqueue I/O thread) and then many other threads can consume it (think, threads that actually perform your server logic). I've found that the "SPMC" concurrency model tends to fit into my pipeline perfectly when I'm working on problems that need a specialized library like this. CK is for achieving unimaginably fast data-parallelism, like the kind you need when writing high performance drivers atop some DMA slab, or (in my case) using userspace networking to do something useful with millions of packets per second. Check out http://concurrencykit.org/articles/ck_hs.html http://concurrencykit.org/articles/ck_hs.html for a better idea about just how fast this library aims to be (spoiler: tens of nanoseconds per op).
sbahra 11y ago
They are. As Alex points out, a fair number are a mixture of single-reader many-writer or many-writer single-writer, and a few are many-writer many-reader. MPMC: ck_stack, ck_fifo, ck_ring (in the works), ck_disruptor (pending push), ck_bitmap (but not linearized) and ck_hp* And in some cases, these are just building blocks for more complex structures. Specialized: - Everything else, including ck_[r]h{s,t}*. The synchronization primitives are all generalized to multiple writers (exception is ck_swlock which is specialized). The manual pages should point out bounded concurrency.

by reza_n 11y ago

alexforster 11y ago

They're mostly all some combination of lock-free/wait-free single-producer multi-consumer datastructures, meaning one thread can produce some data (think, an epoll/kqueue I/O thread) and then many other threads can consume it (think, threads that actually perform your server logic). I've found that the "SPMC" concurrency model tends to fit into my pipeline perfectly when I'm working on problems that need a specialized library like this. CK is for achieving unimaginably fast data-parallelism, like the kind you need when writing high performance drivers atop some DMA slab, or (in my case) using userspace networking to do something useful with millions of packets per second. Check out http://concurrencykit.org/articles/ck_hs.html http://concurrencykit.org/articles/ck_hs.html for a better idea about just how fast this library aims to be (spoiler: tens of nanoseconds per op).

sbahra 11y ago

They are. As Alex points out, a fair number are a mixture of single-reader many-writer or many-writer single-writer, and a few are many-writer many-reader. MPMC: ck_stack, ck_fifo, ck_ring (in the works), ck_disruptor (pending push), ck_bitmap (but not linearized) and ck_hp* And in some cases, these are just building blocks for more complex structures. Specialized: - Everything else, including ck_[r]h{s,t}*. The synchronization primitives are all generalized to multiple writers (exception is ck_swlock which is specialized). The manual pages should point out bounded concurrency.