0

All these frameworks create another level of abstraction on top of Threads. For example using kotlin-coroutines will seemingly require more CPU cycles than pure threads because of scheduling. For reactive we have same situation, extra level - more CPU cycles. Though I don't know about akka-actors.

And still even with more CPU cycles for scheduling of coroutines we still may have performance gains because of non-blocking approach.

Can someone please explain these gains (or is it a trade-offs?) in detail with focus on hardware and OS level? Maybe what are situations when we would want to use coroutines or reactivex and when we don't want to use them because of something?

A. L.
  • 712
  • 1
  • 10
  • 16
  • [Java Memory Model](https://stackoverflow.com/questions/362740/java-memory-model-can-someone-explain-it) is complex and unintuitive. Messing with it directly is error-prone. The frameworks allow you to avoid it – darw Oct 28 '20 at 17:13

1 Answers1

5

Threads, coroutines, actors, etc are all abstractions around concurrent operations. The main tradeoffs here are the number of those concurrent operations and the duration for which they are active.

OS-level threads work really well when you have a few concurrent operations (since each thread expensive) and when all operations do big chunks of CPU-bound work (since switching between threads is very expensive).

User-level abstractions of all sorts that are created on top of OS-level threads work well when you have lots of those concurrent operations and/or they consume very little CPU from their start to finish or from one resumption point to the next suspension, since those abstractions are light-weight and their launching, stopping, and switching between them is very cheap, too.

Roman Elizarov
  • 27,053
  • 12
  • 64
  • 60