Re:Concurrency kit – Concurrency primitives and non-blocking...
by exDM69 on Sunday September 13, 2015 @05:14AM
(#10210775)
OpenMP is a bunch of compiler directives (and a runtime library) for easy data parallelism. E.g. #pragma omp parallel for.
This library is a bunch of concurrent data structures (hash map, producer/consumer queue, etc) for multi threaded applications. This is more oriented to task parallelism than data parallelism (e.g. servers and such). You'd use this library together with pthreads or other threading library.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by zurn on Sunday September 13, 2015 @02:00AM
(#10210495)
Apart from the functional differences,
OpenMP is implemented in compilers and support is currently hit-and-miss even though mainstream compilers are slowly getting there. So eg targeting Mac, Linux and Windows would probably get quite "interesting" if you wanted to support the platform's common vendor-provided compilers.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by mingodad on Sunday September 13, 2015 @05:42AM
(#10210816)
I looked at this library in the past and I could not find any usage of it in any open source project. That made me a bit scary, how a library like this with the supposed well thought construction is not used anywhere ?
Re:Concurrency kit – Concurrency primitives and non-blocking...
by sbahra on Monday September 14, 2015 @01:19PM
(#10216155)
It's used in a lot of mission-critical commercial applications which I think is a stronger indicator. It just so happens those aren't open-source. This ranges from mission-critical enterprise software to internal infrastructure tied directly to revenue generation. There is a serious cost to failure there (money, liability, jobs, etc...).
Few software uses these advanced techniques in general, and it isn't so much about Concurrency Kit. There is a barrier to entry as folks have to invest non-trivial amounts of time in learning more about these techniques.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by reza_n on Sunday September 13, 2015 @12:10PM
(#10211820)
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.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by alexforster on Sunday September 13, 2015 @12:45PM
(#10211932)
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 for a better idea about just how fast this library aims to be (spoiler: tens of nanoseconds per op).
Re:Concurrency kit – Concurrency primitives and non-blocking...
by sbahra on Monday September 14, 2015 @01:02PM
(#10216071)
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.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by justifier on Saturday September 12, 2015 @11:00PM
(#10210205)
if you already have a need of concurrency in your project and want to know how to utilise the library there is a documentation section on the linked page
a good starting point would be the man pages
if you want to know where to start on getting info on how or why you would use a library like this check out the articles or slides section, or wiki around unfamiliar words in the man pages
Re:Concurrency kit – Concurrency primitives and non-blocking...
by Keyframe on Sunday September 13, 2015 @12:40PM
(#10211914)
I was hoping for a mini usage showcase / sample. Maybe I'm spoiled, but I was looking through man pages and it was a meaningless dump to me as a newcomer to the library. I then looked at the articles, but it was a long read I didn't want to do at first.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by sbahra on Monday September 14, 2015 @01:21PM
(#10216163)
I agree. Such an article would be more emphasizing use-cases for different advanced synchronization techniques in context of Concurrency Kit. You may just not have a use for it too.
I'll put up a presentation soon that may be helpful in these regards.
This might not be the intention of the author, but if you want someone to use/hack with your library, please make it human-readable. Those macros reduce the amount of duplication, at the cost of legibility. At least include useful comments... /rant off
Re:Concurrency kit – Concurrency primitives and non-blocking...
by corysama on Saturday September 12, 2015 @07:23PM
(#10209748)
To each his own. As far as macro fests go, that file looks very reasonable and legible to me. It's a single pattern repeated consistently for each function family. Writing out a dozen variants of each function explicitly would not only be much more error-prone, but would also be much harder to read and understand as a whole IMHO.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by alexforster on Saturday September 12, 2015 @09:03PM
(#10209970)
It's actually used as a way to avoid casting into and out of void* on every line. Think C++ templates. The documentation is somewhat lacking, but it's not too hard to figure out the APIs, and once you do, actually using the library is a pleasure.
Re:Concurrency kit – Concurrency primitives and non-blocking...
by sbahra on Monday September 14, 2015 @01:39PM
(#10216282)
Code duplication can also mean more errors and a lot more work for porters. You'll also see plenty of other examples in popular open-source projects such as the Linux and FreeBSD kernel. The reduction in amount of duplication is significant.
For example:
For SPARCv9 for example, the macro system generates 138 functions from only the 25 or so the developer provides. To top it off, this would work across memory models as well.
This library is a bunch of concurrent data structures (hash map, producer/consumer queue, etc) for multi threaded applications. This is more oriented to task parallelism than data parallelism (e.g. servers and such). You'd use this library together with pthreads or other threading library.
Does this answer your question?
Few software uses these advanced techniques in general, and it isn't so much about Concurrency Kit. There is a barrier to entry as folks have to invest non-trivial amounts of time in learning more about these techniques.
Some open-source examples: http://www.machinekit.io/ https://labs.omniti.com/labs/reconnoiter https://github.com/Litres/turboxsl Aerospike
I'm sure there are others, if there's anything I'm missing, would love to hear.
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 for a better idea about just how fast this library aims to be (spoiler: tens of nanoseconds per op).
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.
PS I may be dense today.
a good starting point would be the man pages
if you want to know where to start on getting info on how or why you would use a library like this check out the articles or slides section, or wiki around unfamiliar words in the man pages
I'll put up a presentation soon that may be helpful in these regards.
This might not be the intention of the author, but if you want someone to use/hack with your library, please make it human-readable. Those macros reduce the amount of duplication, at the cost of legibility. At least include useful comments... /rant off
It took me less than a minute scrolling through the file to figure out what's going on.
For example: For SPARCv9 for example, the macro system generates 138 functions from only the 25 or so the developer provides. To top it off, this would work across memory models as well.