[HN Gopher] Concurrencpp - A C++ concurrency library
___________________________________________________________________
Concurrencpp - A C++ concurrency library
Author : concurrencpp
Score : 55 points
Date : 2021-01-01 11:56 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| de_nied wrote:
| > _Being able to write modern concurrency code without having to
| rely on low-level concurrency primitives like locks and condition
| variables._
|
| A concurrency library is useful to have to avoid boiler plate
| code, but it seems like it's made for people who don't have
| knowledge about how concurrency works, and don't plan on
| learning. That being the case, how useful will this library
| actually be? Using it means your code will only be as efficient
| as the library. You'd also be relying on the library developer to
| fix any issues you have, be it with the library or your own
| implementation.
|
| In my experience, when people write libraries for the purpose of
| providing ability to those who can't do it themselves, the
| libraries become more general purpose, which typically ends up in
| less efficient algorithms for the sake of compatibility.
| concurrencpp wrote:
| concurrencpp is inspired heavily from the Java executor API on
| one hand, and C# TPL on the other hand.
|
| This library just fills in what other languages already provide
| in their standard library while C++ still doesn't. Your
| criticism could basically be directed at any programing
| language that provide high-level structured concurrency that
| doesn't rely on raw threads and locks.
|
| I do agree that basic understanding of classical concurrency,
| the correct use of threads, locks and condition variables is
| essential for every developer who wants to write any correct
| concurrent code.
|
| Another thing is, that developers can not learn everything. The
| chances that a non-concurrency hobbist/expert writes a correct
| and efficient thread pool, for example, is slim. Developers
| should not write their own concurrency infrastructure, they
| should use something correct and efficient. this is what
| concurrencpp provides.
| atty wrote:
| As others have pointed out, I think your argument is pretty
| flawed. Consider, for instance, the following...
|
| An operating system is useful to avoid boiler plate code, but
| it seems made for people who don't have knowledge about how
| hardware works, and don't plan on learning. That being the
| case, how useful with this operating system be? Using it means
| your code will only be as efficient as the operating system.
| You'd also be relying on the OS developer to fix any issues you
| have, be it with the OS or your own implementation.
|
| We can go up and down the stack from transistors to programming
| languages to full applications with the same argument. And at
| each step it misses the point that abstraction layers are
| probably the most powerful and successful concept we've applied
| in hardware and computer science, and there's no reason that
| concurrency would be any different.
| jcelerier wrote:
| > You'd also be relying on the library developer to fix any
| issues you have, be it with the library or your own
| implementation.
|
| what's the difference with literally every other stack ? do you
| also write your own libc ?
| wrsh07 wrote:
| _someone writes a library of abstractions_
|
| You: "these abstractions are only useful if you don't know how
| to use the underlying primitives"
|
| This is obviously nonsense. Abstractions are useful because
| they can simplify your code while providing good performance.
| Because certain things (eg optimizing, reasoning about locks,
| writing tests for a concept) are expensive and it's better to
| only do them once really well.
|
| If a pattern is regularly repeated, it often makes sense to
| abstract it. Why would that be any different in code that deals
| with concurrency??
| bern4444 wrote:
| > You'd also be relying on the library developer to fix any
| issues you have, be it with the library or your own
| implementation.
|
| Isn't this the entire premise behind open source software?
| You're always relying on the maintainers and contributors to
| resolve bugs you may encounter. But because its open source,
| anyone can simply open a PR with the fix.
|
| > Using it means your code will only be as efficient as the
| library.
|
| Certainly true, but for most people and projects speed of
| delivery is more important than speed of the application. We
| take on some tech debt now to get to market more quickly and
| address that tech debt later on.
|
| One cannot take responsibility for an individual's misuse of
| your product. If people use this library incorrectly, then its
| not really the author's fault...
|
| I'd hope the author added some guidelines of how to use this
| and wrote the library in a way that encourages proper and good
| use to minimize incorrect use but its on the consumer to
| integrate the library correctly
| 29athrowaway wrote:
| If you want to learn more about how to implement multi-threaded
| C++ software, I strongly recommend this CppCon talk titled
| "Multithreading is the answer, what is the question?"
|
| - https://www.youtube.com/watch?v=GNw3RXr-VJk
|
| - https://www.youtube.com/watch?v=sDLQWivf1-I
| loeg wrote:
| Facebook's Folly provides something similar:
| https://github.com/facebook/folly/tree/master/folly/experime...
| stormbeard wrote:
| I was going to say this exact same thing. Their executors are
| also more widely adopted and worth mentioning:
| https://github.com/facebook/folly/blob/master/folly/docs/Exe...
| cosmotic wrote:
| What does modern mean in this context?
| colejohnson66 wrote:
| "Modern C++" is a phrase to refer to newer C++ versions. In
| this case, it's C++20.
| stormbeard wrote:
| From my experience, people say "Modern C++" to mean C++11 and
| newer. That was a real turning point and when I started to
| see that phrase used.
| mehrdadn wrote:
| Yeah I agree. It's just meant to distinguish from legacy
| C++, basically the era before unique pointers (and thus
| move semantics etc.).
| blux wrote:
| Also worthy of mention in this context:
| https://github.com/facebookexperimental/libunifex
|
| "The 'libunifex' project is a prototype implementation of the C++
| sender/receiver async programming model that is currently being
| considered for standardisation."
___________________________________________________________________
(page generated 2021-01-01 23:01 UTC)