Coroutines

[Biterider]

Hi
I want to start a discussion about coroutines.
They're a relatively old concept, before pre-emptive multitasking was implemented, but some people claim that they're still useful and that they can only be implemented using assembler. That last statement caught my attention and I took a closer look at this technique.
One of the challenges I see is the context switches and their high cost in terms of speed. I found some APIs that did the hard work so that at the end a testbed can be created to validate the whole concept.
What bothers me the most is that I don't see any advantage over well-prepared code that is broken up into short routines that are called one after the other. This is a much cleaner approach in my opinion without all the complexity of managing an execution context.
Maybe I'm missing something, so I'm interested in your opinion and experience on this topic.

Biterider

[jj2007]

Hi Biterider,

That sounds way more interesting than the endless covid and Ucraine threads, but perhaps you should give us some meat to put our teeth into: what exactly do you mean with "coroutines"? How are they different from simple threads on the one and Switch... Case... Endsw constructs on the other hand?

[Biterider]

Hi
Sorry... I was so focused on the topic that I forgot to give you more context. 

Coroutines are a superclass of regular routines. The concept comes from the time of cooperative multitasking. The core idea is to stop a longer-running routine at certain points in the code, switch context, and pass control to another routine. Sometime later, the context of the first routine is restored and control is transferred back to the point where it was interrupted.
This process continues until the routine reaches its end.

Wikipedia has a very good article on this https://en.wikipedia.org/wiki/Coroutine 

Biterider

[jj2007]

I've seen the article, but I can't see the big difference to CreateThread & friends...

[Biterider]

Hi JJ
That's my point too.
The difference that one is pre-emptive and the other cooperative.
The first has a known overhead of switching from one thread to another, while the second should be less expensive depending on your implementation, and it is always single-threaded. This reduces some synch. complexity and an speedup in some cases.

When you look at how it can be implemented, you immediately concluded that you need a strategy for preserving and restoring context. Luckily, there are some APIs that do this work for you. Without having tested it, I suspect that this is not a lightweight thing.

Biterider

[jj2007]

My standard procedure in Gui applications is:
- CreateThread...
- Threadproc proc
  ... do work ...
  when ready, SendMessage hMainWindow, WM_THREADHASDONEITSWORK, result1, result2
  ret
  ThreadProc endp
- Switch uMsg
  Case WM_THREADHASDONEITSWORK
      react

So what's the added value of a coroutine?

[Biterider]

Hi JJ
That's my question
What are the benefits of coroutines?

Are they easier to program at the expense of execution speed?
Are they faster than preemptive multitasking? Always or just in some situations?

Before I go any deeper, I want to understand the goals properly...

Biterider

[HSE]

Hi!!

From most complete ignorance, I have the idea that OS can run a Thread in a different core. But if coroutines don't interact with OS they are monocore by force. No?

[jj2007]

It could just be HLL fake. A name that doesn't mean much, a name for things we do all the time in Assembly. But to understand, we would need a real life example...

[HSE]

Look like Kotlin coroutines have little to do with Knuth coroutines:

The CoroutineDispatcher that is designed for offloading blocking IO tasks to a shared pool of threads.

This HLL coroutines are some kind of big architecture.

[jj2007]

designed for offloading blocking IO tasks to a shared pool of threads

Now explain what is the difference to CreateThread. It's not a "shared" "pool", whatever the philosophical content of these wise words might be (the opposite would be "unshared non-pooled single thread"), but otherwise it looks like the exact definition of a thread's purpose. Offload blocking IO tasks, yeah, that's it. Download a web page without making the application unresponsive, for example. Sounds less professional than "offloading blocking IO tasks to a shared pool of threads", but it's trivial, and trivial tasks do not need that aura of professionalism imho.

[Biterider]

Hi
@HSE: IMHO, Kotlin uses a completely different approach than Donald Knuth's original definition. Reading about this topic, I noticed that the actual implementation varies a lot from language to language.
@JJ: you have to think about when the term coroutine was coined and what the technological status was at that time.

I checked the MS page that describes the so-called fibers. They come very close to what Kunth intended. Just replace the API names with Kunth's and you have a pretty close match.
https://docs.microsoft.com/en-us/windows/win32/procthread/fibers

Biterider

[jj2007]

In general, fibers do not provide advantages over a well-designed multithreaded application.

Says Micros**t

Actually, I had read about fibers years ago, but since virtually nobody uses them, I lost interest.

[FORTRANS]

Hi,

   After reviewing my notes, I found a program I wrote to
implement a coroutine after reading about them in Knuth's
book.  So a routine that gets user input and updates the
upper display.  If a request from the user to go to the bottom
of the screen is seen, a jump to the other routine is made.
Which gets user input and updates the lower screen until a
request to go to the upper display is seen.

   Unfortunately, the comments in the program state that it
didn't really get the intended job done.  Supporting Knuth's
comment that it is difficult to find a good, small example of
coroutines.  But it is easy to write a really clunky one.

Cheers,

Steve N.

[jj2007]

Here is an explanation with some examples, although I have no clue what they really want to say or to achieve