> Concurrency is also not more efficient on a single core.

Concurrency can be more efficient even on a single core. When blocking synchronous I/O is involved, concurrency may help saturate the bandwidth with multiple in-flight requests.

if you are in an I/O bound situation, then yes, concurrency will allow you to exploit some parallelism.

Otherwise, no.

(and in general, people just throw concurrency at the problem instead of analysing whether they are in fact I/O bound or CPU bound).

(Downvoted why??)

you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%

...and that is true.

When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?

People that end up in a position to care about performance are using profilers and bechmarks. This is actually the first rule: don't guess, measure.

Of course it helps when the platform has the proper tools for it. I end up using JMH and YourKit Profiler weekly, because a memory or CPU leak can crash our process and we have pretty strict reliability requirements with a single server processing about 5000 events per second - not extremely demanding, but when it crashes, we can lose money, with the redundancy infrastructure being pretty new.

This very thing has occupied my day job for at least four months now. It happens when a pre-existing system one has to improve has lots of DB-heavy and compute-heavy operations commingled.

Yesterday?

> I think the first thing people should be taught about concurrency... is when not to use it.

Concurrency is usually not a feature of the algorithm but a feature of the problem domain. If you have many requests coming in at the same time, all competing for a limited amount of computational resources -- you have concurrency.

How you handle it is a different matter. You can decide to handle the requests one by one, but then, by Little's law, your throughput would be very low, and your server will crash if the rate of requests is over some small limit (which depends on the time it takes to service each request).

No. If the problem is computational resources, performance can't be increased by mere concurrency (while even completely deterministic STM-style parallelism would help).

Concurrency improves performance when a process accesses both the same computational resource and some other high-latency sharable resource.

What is your "no" referring to? I totally agree with you. When I said "computational resource" I wasn't referring necessarily to CPU, let alone on the same machine, but resources of any kind. When one request is blocked, say, waiting for the DB (a computational resource), another can do some computation.

I think you're confusing concurrency with parallelism. Indeed, when these two are combined in the same process with multiple threads sharing memory or other resources, you're effectively juggling with knives.

But in fact concurrency is inevitable in absence of OS threads that can be blocked (another potential clusterfuck) or of some form of continuations support, because it is a direct consequence of asynchrony.

And asynchrony isn't avoidable, all you can do is to find abstractions that make it more deterministic.

The next thing they should be taught is that even if an existing serial implementation can be made more efficient using concurrency, that doesn't mean it should be. That should be followed quickly by teaching that concurrency should be implemented over the smallest possible surface of the code.

absolutely!

Do you have any suggestions of ressources to learn more on that specific topic. I am interested on ressources to learn more about when to use tasks or when it is better not to. Especially for embedded systems. I find now people use tasks for anything without having a real idea of the costs. I am also interested on when it is needed to use an embedded OS or when you could better do without one. Any kind of ressources, book, website etc is welcomed.

Unfortunately, this is the type of real-world problem that isn't well taught (or even documented).

We are all taught from uni about how concurrency is implemented and most applications use concurrency as a design-tool to decompose a problem into its functions.

Unfortunately, this tends to produce a sub-optimal result as the inefficiencies become visible on small embedded/real-time systems.

Its difficult to give any general advice, but have a look at real-time analysis to get an idea of the real issues.... and don't blindly throw tasks at a problem when a simple superloop is more efficient/simple/maintainable.

> Concurrency is also not more efficient on a single core.

This isn't a hard and fast rule. There is overhead to parallelism.

And if you step out all the parallelism from your concurrency runtime, you get rid of a big chunk of the overhead. But even with purely cooperative single-threaded multitasking, there's still some overhead vs "ordinary" strictly serial code.

For CPU bound code, concurrency is pure overhead.

For I/O bound code, concurrency can give you some benefit.

...but in general, people do not analyse this before throwing tasks at a problem.

> ...but in general, people do not analyse this before throwing tasks at a problem.

Would that be just anecdotal ?

yes... in ~25 years in the business, over ~10 companies.

..and I can tell you that precisely none of them performed a correct analysis of a systems concurrency needs before 'designing' it.

A common artifact of this is far too many tasks.

I have seen egregious abuse of pre-emptive threads ... a lot. Abuse of green threads / fibres / coroutines ... not so much. I think one has to be a half decent programmer to be even aware those options.