GCC 11 Enables Co-Routines Support In C++20 Mode

[ssokolow]

well, just like ordinary functions could be run in parallel if someone will run them in parallel. which doesn't make ordinary functions threads and it doesn't make coroutines threads

Of course not. My point is that whether they are run in parallel and under what circumstances is an implementation-dependent detail.

Fundamentally, they are a form of M:N cooperative multi-threading (while what we think of as threading today is 1:1 pre-emptive multi-threading), and some implementations set M to 1 (implemented on top of a single thread).

[pal666]

Actually, coroutines do run concurrently, they just don't run in parallel. But I'm just posting this for correctness' sake, I frequently mix those two up myself.

well, the only thing they do concurrently is wait. do you consider normal function to be running concurrently with its caller?

[pal666]

Whether they run in parallel (they execute concurrently by definition) depends on the implementation.

well, just like ordinary functions could be run in parallel if someone will run them in parallel. which doesn't make ordinary functions threads and it doesn't make coroutines threads

[bug77]

Of course you haven't really had fun until you've programmed on a system with preemptive multitasking and no memory protection between the different processes or the OS. That'll put hair on your chest! And gray hair on your head. One bad pointer and Boom!, down goes the whole system.

Luckily "the whole system" was just your own PC, but still.

I did that, but only for a semester, before I decided going that low-level is not my cup of tea.
I liked doing UIs and presenting stuff. Of course, I ended up mostly as a back-end developer :P Plenty of threads to mess up there, too, but since I'm not doing C/C++, they're the tamer variety.

[ssokolow]

stackful and stackless both have their pros and cons, it's good to have both(or something combined, and there was an effort to combine them, but it wasn't successful yet)
microsoft was impatient because they need them for their api

Microsoft actually leapt on the stackful coroutines bandwagon back in the early Windows NT days and provided OS-level support for fibers. Here's a writeup on why they consider the WinAPI fiber support deprecated:

Fibers under the magnifying glass by Gor Nishanov

coroutines have nothing to do with threads, they are syntactic sugar for callbacks(single threaded). they don't run concurrently and do not require synchronization, which has impact on reasoning and on execution

Whether they run in parallel (they execute concurrently by definition) depends on the implementation. For example, in Rust, thanks to the data race guarantees provided by the language, an async executor is free to farm the async tasks out over a thread pool without worry.

[Mark625]

Yes, I know all that.
I was just saying, when things are so clear cut, along comes Java and adds yield() to Thread. I'm sure many beginners fell for that.

Of course you haven't really had fun until you've programmed on a system with preemptive multitasking and no memory protection between the different processes or the OS. That'll put hair on your chest! And gray hair on your head. One bad pointer and Boom!, down goes the whole system.

Luckily "the whole system" was just your own PC, but still.

[bug77]

co-routines and other types of async / await programming rely on yield. Otherwise there would be nothing concurrent about it.

Yield in real threads is always a mistake because it indicates that the programmer doesn't know what their thread is supposed to be doing. If it is supposed to run, then run. If it is supposed to be waiting on some event, then wait on that event. If it is low priority then set a low thread priority. Not this, Oh I might be using too much time so I should see if some other thread wants to butt in.

Yes, I know all that.
I was just saying, when things are so clear cut, along comes Java and adds yield() to Thread. I'm sure many beginners fell for that.

[Zan Lynx]

And yet, the Thread class in Java has a yield() method
I will always remember what a teacher (RIP) taught us in college: when you feel the need to yield(), take a step back and look at the bigger picture - there's a problem somewhere. A simple piece of advice that has kept me out of trouble for almost two decades now.

Of course, outside of this particular peculiarity, was you wrote is spot-on. I also don't know whether, like in the traditional cooperative multitasking case, when one coroutine doesn't play ball, it messes with the other coroutines on the same thread.

co-routines and other types of async / await programming rely on yield. Otherwise there would be nothing concurrent about it.

Yield in real threads is always a mistake because it indicates that the programmer doesn't know what their thread is supposed to be doing. If it is supposed to run, then run. If it is supposed to be waiting on some event, then wait on that event. If it is low priority then set a low thread priority. Not this, Oh I might be using too much time so I should see if some other thread wants to butt in.

[bug77]

The defining characteristic of co-routines is a voluntary yield() call that passes control to the next co-routine (or a dispatch function). After the other co-routine finishes its work and yields, control is returned back to this function after its yield() call. This is usually in a tight loop.

Threads are preemptively scheduled and do not need to yield.

And yet, the Thread class in Java has a yield() method
I will always remember what a teacher (RIP) taught us in college: when you feel the need to yield(), take a step back and look at the bigger picture - there's a problem somewhere. A simple piece of advice that has kept me out of trouble for almost two decades now.

Of course, outside of this particular peculiarity, was you wrote is spot-on. I also don't know whether, like in the traditional cooperative multitasking case, when one coroutine doesn't play ball, it messes with the other coroutines on the same thread.

[Mark625]

The defining characteristic of co-routines is a voluntary yield() call that passes control to the next co-routine (or a dispatch function). After the other co-routine finishes its work and yields, control is returned back to this function after its yield() call. This is usually in a tight loop.

Threads are preemptively scheduled and do not need to yield.