3

After coming across the concept of co-routines in Lua I feel that these seem to be a much better model for programming concurrent software and i'm wondering why there was not used in Java?

Co-routines seem to let the developer write code which jumps between multiple functions, progressing each a few steps at a time, providing the illusion of concurrent execution, in much the same way as the CPU would time slice between multiple threads in Java, however co-routines allow the developer to decide when to jump out of one function and start executing another. This allows the developer to decide how fine grain the steps should be, ie the degree of concurrency, and when the context switch should occur, which could prevent costly context switches when latency is critical.

newlogic
  • 807
  • 8
  • 25
  • 2
    It's very hard to answer these "Why didn't X do Y?" questions. We're not privy to the design decisions, usually. Would you be interested in answers to a question like: "What are some benefits of using a threading model vs. co-routines?" – Alex Feinman Oct 22 '13 at 18:54
  • Sure i'll check out that question thanks. – newlogic Oct 22 '13 at 18:56
  • @user1037729 Coroutines offer a way to control flow in the problem. Themselves they have nothing to do with concurrency (Well.. if you implement things like C#'s async/await they provide nice _syntactic sugar_ but that's not _really_ the coroutines working there). Your question is like "Why does Java use a thread abstraction instead of for loops". – Benjamin Gruenbaum Oct 22 '13 at 19:14
  • More often than not your running more threads than you have cores and therefore two or more threads are sharing a core which means the execution of these threads is happening in steps, which is must the same was as a co-routine would operate, so I wouldn't say they are that much different, unless you have a thread per core. – newlogic Oct 22 '13 at 19:22
  • Coroutines allow to "freeze" the execution of a function, and resume at the same point or another. This allows for an impression of multiple executing threads, although not concurrently. The comparison is therefore not absurd as @BenjaminGruenbaum is insisting on. – Tarik Oct 22 '13 at 19:31

1 Answers1

8

Coroutines are powerful but will not replace full fleged multithreaded applications, because coroutines run on a single thread. As such they will not make use of multiple cores when needed for CPU intensive tasks. I see them as representing a complementary paradigm rather than a competing one. Functional programing is making a headway into Java as it has already done on the .Net platform. Coroutines will eventually follow suite. I suggest you to look at the Java roadmap for more info. See Processes, threads, green threads, protothreads, fibers, coroutines: what's the difference? for a more elaborate answer that covers coroutines and other concepts. See also Throughput differences when using coroutines vs threading that discusses the implementation of the producer consumer problem with coroutines instead of multiple threads.

Community
  • 1
  • 1
Tarik
  • 10,810
  • 2
  • 26
  • 40
  • +1 for clean answer :) – Sage Oct 22 '13 at 19:12
  • Who said coroutines have to run on a single thread? Coroutines are just a construct. In themselves they have nothing to do with concurrency of the whole program. This whole question is like asking "Can I replace this duck with a trampoline". – Benjamin Gruenbaum Oct 22 '13 at 19:12
  • @BenjaminGruenbaum That's not what I said. Unless we use coroutines in the context of multiple threads, they will not run multithreaded by magic. Coroutines are not a replacement for multithreaded capabilites offered by the thread library. – Tarik Oct 22 '13 at 19:17
  • @BenjaminGruenbaum see the reference I added to find out how ducks enjoy jumping on a trampoline :-) – Tarik Oct 22 '13 at 19:26