Concurrencpp – A C++ concurrency library
github.com
github.com
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.
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.
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++.
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??
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.
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.
I (GP) was actually saying exactly what kjeetgill was saying. I think you are misunderstanding our points.
> They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives"
What I said was that this library is geared towards people (not beginners, anyone) who do not understand and don't plan on learning the concepts that are extremely important and fundamental in the use of a language. You make good points with abstraction, but what I said was based on the context. The context is that we're talking about something (concurrency) that fundamental in knowing when using something else (C++).
As I stated in my original reply, "A concurrency library is useful to have to avoid boiler plate code...." I agree with you that libraries are good for abstraction for things we either repeat or already know. They are not good when used as substitutes for the lack of knowledge, when that knowledge is as foundational as concurrency is in C++.
> 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"
The actual variable we're using here to determine of what should be understood and what's not that important to be understood is how closely the two subject matters are related and (here it comes, my favorite word) fundamental to each other.
> 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 might be sounding like a broken record, but just to make sure I'm clear on what I meant. Use the library by all means, unless it's to avoid learning something fundamental (buzzword of the day folks).
I'm trying to push back against this notion that libraries are bad. That people should learn programming one specific way.
I think this idea is often well-intentioned. For JavaScript, it has been "you don't need jquery" for a long time. And you probably don't need jquery, but I generally think you should feel free to use tools that help you accomplish your goals.
I agree that learning concurrency primitives in c++ is useful and rewarding, but pedagogically I don't endorse any particular entry point to parallelism.
That said, once you've found that you do need concurrency for your task, yes, absolutely learn the fundamentals. They're called fundamentals for a reason.
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.
what's the difference with literally every other stack ? do you also write your own libc ?
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
"The 'libunifex' project is a prototype implementation of the C++ sender/receiver async programming model that is currently being considered for standardisation."