4 ms·

Concurrencpp – A C++ concurrency library

63 points by concurrencpp 6y ago

de_nied 6y ago
> 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.
- bern4444 6y ago
  > 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
- concurrencpp 6y ago
  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.
- jcelerier 6y ago
  > 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 ?
- atty 6y ago
  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.
  - de_nied 6y ago
    I see your point, but, I disagree with you because your comparison example has a much larger difference in the relation between the two subjects. Learning the concepts behind operating system design isn't crucial or needed for something like web development. However, concurrency is something that's used and fundamental when programming in C++, and learning it should not side-stepped with libraries. Yes, you are correct to state that it's basically all relative and based on opinion and therefore we could go around in circle all day comparing everything. But I think that my point is a fair one when you have two things as closely related as concurrency and C++.
- wrsh07 6y ago
  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??
  - kjeetgill 6y ago
    > This is obviously nonsense. ... Why would that be any different in code that deals with concurrency?? I know you're speaking more broadly about abstraction as well as concurrency, but I share the GP's instincts on this. Because of the limitations (or rather the lack of limitations) in languages like C++ or Java its very easy write code that undoes any useful work a concurrency abstraction might provide. These abstractions are still useful! But they still require above average knowledge of their internals compared to say data-structures. With concurrency, things just don't compose that well without a ton of implicit best practices. The most trivial example is using a FooServiceClient from multiple threads and that ends up secretly holding long-lived locks internally essentially serializing your whole server. It happens accidentally all the time.
    - wrsh07 6y ago
      You and the post I'm responding to are saying slightly different things. They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives" I disagree with the premise. When you use a tool, you don't need to understand the internals, but depending on documentation, error messages, and the surrounding community you can learn what's going on under the hood as you need to. When I use a library I don't plan one way or the other to become a deep expert or stay a beginner. I develop the knowledge I need to solve my problems. The tool is useful at all points in my own progression - from being a good place to learn about and practice using concurrency to being a codebase I can browse to learn more about how the primitives work. You're saying "concurrency is harder than other abstractions, so in order to use it correctly you actually need to understand what's going on" I also disagree with that premise. There are lots of hard things in programming. Concurrency is one of them, but so is memory management. There are footguns all over. It's possible to misuse most abstractions, and the reasoning could often be chalked up to "not understanding underlying primitives" I think this is all besides the point. If you run into problems when using your tool, you will have to learn how to fix or debug them. If in the case of serializing your whole application: either your application didn't need to be parallelized or you will debug why it's not scaling like it should be. That step, the debugging what's wrong... it's going to make you learn a little bit more about what's going on under-the-hood. I think all of us agree about that. So what are you and the original post I was responding to saying? I think the first post was saying something like "you should learn concurrency primitives; if you know concurrency primitives, then this library is overly pedantic." I don't really know what you're saying. I'm saying: use whatever entry point you want to solve your problems. It seems very likely to me that the abstractions provided here will make sense to some people (eg maybe they've learned idiomatic go concurrency or used kotlin coroutines), but they might be brand new to others. If the examples are sufficient for you to get concurrent code working, then that is really great! I'm not sure why people insist that we learn things one way or in some specific order. I don't see their research indicating that bottom up is better for retention (or something else), they are simply positing without fact that their way is best. I disagree.
loeg 6y ago
Facebook's Folly provides something similar: https://github.com/facebook/folly/tree/master/folly/experimental/coro#introduction https://github.com/facebook/folly/tree/master/folly/experime...
- stormbeard 6y ago
  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/Executors.md https://github.com/facebook/folly/blob/master/folly/docs/Exe...
blux 6y ago
Also worthy of mention in this context: https://github.com/facebookexperimental/libunifex 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."
29athrowaway 6y ago
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=GNw3RXr-VJk - https://www.youtube.com/watch?v=sDLQWivf1-I https://www.youtube.com/watch?v=sDLQWivf1-I
cosmotic 6y ago
What does modern mean in this context?
- colejohnson66 6y ago
  “Modern C++” is a phrase to refer to newer C++ versions. In this case, it’s C++20.
  - stormbeard 6y ago
    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 6y ago
      Yeah I agree. It's just meant to distinguish from legacy C++, basically the era before unique pointers (and thus move semantics etc.).

63 points by concurrencpp 6y ago

> 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.

bern4444 6y ago
> 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
concurrencpp 6y ago
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.
jcelerier 6y ago
> 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 ?
atty 6y ago
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.
- de_nied 6y ago
  I see your point, but, I disagree with you because your comparison example has a much larger difference in the relation between the two subjects. Learning the concepts behind operating system design isn't crucial or needed for something like web development. However, concurrency is something that's used and fundamental when programming in C++, and learning it should not side-stepped with libraries. Yes, you are correct to state that it's basically all relative and based on opinion and therefore we could go around in circle all day comparing everything. But I think that my point is a fair one when you have two things as closely related as concurrency and C++.
wrsh07 6y ago
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??
- kjeetgill 6y ago
  > This is obviously nonsense. ... Why would that be any different in code that deals with concurrency?? I know you're speaking more broadly about abstraction as well as concurrency, but I share the GP's instincts on this. Because of the limitations (or rather the lack of limitations) in languages like C++ or Java its very easy write code that undoes any useful work a concurrency abstraction might provide. These abstractions are still useful! But they still require above average knowledge of their internals compared to say data-structures. With concurrency, things just don't compose that well without a ton of implicit best practices. The most trivial example is using a FooServiceClient from multiple threads and that ends up secretly holding long-lived locks internally essentially serializing your whole server. It happens accidentally all the time.
  - wrsh07 6y ago
    You and the post I'm responding to are saying slightly different things. They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives" I disagree with the premise. When you use a tool, you don't need to understand the internals, but depending on documentation, error messages, and the surrounding community you can learn what's going on under the hood as you need to. When I use a library I don't plan one way or the other to become a deep expert or stay a beginner. I develop the knowledge I need to solve my problems. The tool is useful at all points in my own progression - from being a good place to learn about and practice using concurrency to being a codebase I can browse to learn more about how the primitives work. You're saying "concurrency is harder than other abstractions, so in order to use it correctly you actually need to understand what's going on" I also disagree with that premise. There are lots of hard things in programming. Concurrency is one of them, but so is memory management. There are footguns all over. It's possible to misuse most abstractions, and the reasoning could often be chalked up to "not understanding underlying primitives" I think this is all besides the point. If you run into problems when using your tool, you will have to learn how to fix or debug them. If in the case of serializing your whole application: either your application didn't need to be parallelized or you will debug why it's not scaling like it should be. That step, the debugging what's wrong... it's going to make you learn a little bit more about what's going on under-the-hood. I think all of us agree about that. So what are you and the original post I was responding to saying? I think the first post was saying something like "you should learn concurrency primitives; if you know concurrency primitives, then this library is overly pedantic." I don't really know what you're saying. I'm saying: use whatever entry point you want to solve your problems. It seems very likely to me that the abstractions provided here will make sense to some people (eg maybe they've learned idiomatic go concurrency or used kotlin coroutines), but they might be brand new to others. If the examples are sufficient for you to get concurrent code working, then that is really great! I'm not sure why people insist that we learn things one way or in some specific order. I don't see their research indicating that bottom up is better for retention (or something else), they are simply positing without fact that their way is best. I disagree.

loeg 6y ago

Facebook's Folly provides something similar: https://github.com/facebook/folly/tree/master/folly/experimental/coro#introduction https://github.com/facebook/folly/tree/master/folly/experime...

stormbeard 6y ago
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/Executors.md https://github.com/facebook/folly/blob/master/folly/docs/Exe...

blux 6y ago

Also worthy of mention in this context: https://github.com/facebookexperimental/libunifex 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."

29athrowaway 6y ago

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=GNw3RXr-VJk - https://www.youtube.com/watch?v=sDLQWivf1-I https://www.youtube.com/watch?v=sDLQWivf1-I

cosmotic 6y ago

What does modern mean in this context?

colejohnson66 6y ago
“Modern C++” is a phrase to refer to newer C++ versions. In this case, it’s C++20.
- stormbeard 6y ago
  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 6y ago
    Yeah I agree. It's just meant to distinguish from legacy C++, basically the era before unique pointers (and thus move semantics etc.).