Coroutines are now in Clang trunk, libc++

https://twitter.com/eric01/status/867473461836263424

by davedx • 9 years ago

282 170 9 years ago

Some resources for those who aren't too active in keeping up with C++, these slides are a good quick summary[0]. The talks linked on this page[1] are particularly good, especially the CppCon16 Gor Nishanov talk[2]. Paulo[3] has some interesting things to say (though I think some semantics may have changed since, so grain of salt and all).

[0] https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-cor... Interesting to note, slide #11 uses a tokenizer to demonstrate the usefulness of coroutines. IIRC, Rob Pike used a very similar (maybe his was a lexer/parser?) example in '14 re: Go.

[1] http://luncliff.postach.io/post/exploring-msvc-coroutine

[2] https://channel9.msdn.com/events/CPP/CppCon-2016/CppCon-2016...

[3]https://paoloseverini.wordpress.com/2015/03/06/stackless-cor...

Side-note : Love it or hate it, the C++ community is certainly moving at a vibrant pace. I don't write production C++ code anymore (and haven't for a long time) but I still go out of my way to watch the CppCon talks. IMO, they consistently produce best quality talks just because you have so many excellent programmers from various industries using select subsets of C++ in all sorts of different ways. The people writing games are focused on making sure they're portable 'enough' to hit all the major platforms, without getting too tied to platform-specific low-level calls, while retaining the necessary performance to get satisfactory models/meshes/lighting/collision detection/raytracing/dozens-of-other-things completed within that tiny 16.33 millisecond gap to complete the framebuffer and swap in the next frame. The academics who are doing vast numerical computations will be talking about their new MPI utilizations (and undoubtedly, next years talk will be re: a boatload of RDMA/NUMA optimizations). People complain that C++ is a mishmash of too many concepts (pun not intended). I.e., you can write it in the "C with Objects" style, or the "I use TMP so much my code is basically Haskell", and anywhere in between - but it's that heterogeneity that ends up yielding such high caliber talks.

Cyph0n• 9 years ago

People complain that C++ is a mishmash of too many concepts [...] but it's that heterogeneity that ends up yielding such high caliber talks.

I agree. Scala gets the same kind of criticism, but just like with C++, you can easily limit Scala to whatever subset suits you (e.g., pure OOP or pure FP). C++ and Scala are among my favorite languages to work with, so I might be slightly biased :P

pjmlp9• 9 years ago

Also if one looks at any successful programming language in the market that began by fighting complexity, it is easy to observe that they had to eventually embrace complexity to adapt and survive in the market of programming languages.

Even if they kept the core simple, the complexity was shovelled into the libraries instead.

For example, I doubt there is anyone able to know the complete Python 3.6.1 documentation by heart, plus all major libraries, tools and implementations. Yet it is touted as a simple language.

JustSomeNobody• 9 years ago

Kotlin has been in everyone's ear lately and it gets praised for borrowing concepts from many different languages.

Sigh. Go figure.

imron• 9 years ago

Link [0] is broken. It's missing 'abstraction' at the end.

Curbfoot• 9 years ago

Link [0] is broken / missing one word at the end. iheartmemcache probably meant: https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-cor...

colejohnson66• 9 years ago

At the moment, they are still listed as a WIP[0], but the commit history shows a lot of effort done recently[1] (Ctrl-F "coroutine")

[0] https://clang.llvm.org/cxx_status.html#ts [1]: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-2017...

EricWF3• 9 years ago

The changes literally landed in the past three days; The implementation is theoretically perfect, but once it's (seriously) observed by users it will decay into bugs. That's just basic quantum CS. :-)

Cieplak5• 9 years ago

Modern C++ can be very pythonic. Still not as easy as writing Java in IntelliJ but CLion is becoming quite good (if you succumb to CMake). People write shit code in every language; C++ has my favorite abstraction to performance ratio.

http://preshing.com/20141202/cpp-has-become-more-pythonic

pjmlp9• 9 years ago

It became my next favourite language in 1993, after I start looking to a Turbo Pascal successor outside MS-DOS/Windows and C failed to impress me.

Don't use it as I used to, but the improvements in the last years, specially after the introduction of AST libraries via clang, have done wonders to the eco-system.

Now we just need C++ IDEs to catch up with Energize C++ and VA C++ v4, on their Lisp/Smalltalk like experience.

ShabbosGoy• 9 years ago

The language has definitely come a long way. Coroutines are definitely a useful addition to clang. It was my #2 choice for writing a middleware for Elasticsearch, however I ultimately chose Golang because I didn't want to deal with CMake.

Cieplak5• 9 years ago

IPython has always been my favorite interactive UI, so if I had a ton of money to blow on tools, I'd love a more polished Cling (syntax highlighting, intelligent auto-completion, inline docs, emacs/vi keybindings)

https://github.com/vgvassilev/cling

josteink• 9 years ago

CLion is becoming quite good (if you succumb to CMake)

As someone who rarely dabbles in C/C++, but still has some CMake under his belt... What's wrong with Cmake?

I must admit for the use-cases I had, I found it quite a improvement over regular make.

Cieplak5• 9 years ago

I'm sorry; didn't mean to imply there was anything wrong with CMake, meant more as a joke and to suggest that CMake is a new tool that requuires a learning curve, like anything new, hence people resist, until it becames so prevalent that one gives up resisting and invests the time to learn it. In my case, it was to get CLion's external library interface working so I could jump to definition in headers in /usr/local/include

simias• 9 years ago

Nitpick: despite its name CMake doesn't really replace make (actually you can use it to generate Makefiles instead), it's more of a build configuration system like autotools.

As for criticisms of CMake, when I used it I thought it worked pretty well but I think its CMakeLists syntax is atrocious. Not that it's not an improvement over the autotools, but at least these ones have the excuse of being built on top of a mountain of legacy subsystems with various quirks.

MereInterest3• 9 years ago

Cmake is acceptable for distribution, but not for ease of development, in my experience. There should only be a single step needed to generate a correct build, no matter what has changed. Instead, some changes require running make (e.g. modifying existing files), while others require running cmake then make (e.g. adding new files, or changing header file includes). Why would I use cmake when I could just write a makefile to handle everything in a single step?

Granted, I've been moving more towards scons lately, as python is a much easier language to work with. My usual SConstruct will check whether I am making a python extension module, and will download pybind11 if I am. That sort of thing is still possible with make, but starts getting more painful.

17123129• 9 years ago

Cmake is more of a replacement for autotools than for make.

Advantages: Good Windows support.

Disadvantages: Dictates the directory structure, much less flexible than autotools.

If you know shell, an existing autotools project can be modified easily.

If you want to do something special in cmake, first you need to go to Stackoverflow. If your are lucky, the thing you want to do is supported (often it is not).

All in all, I feel locked in by cmake - to the point that once the build works I'm less inclined to refactor because the directory structure cannot be changed easily.

ihnorton2• 9 years ago

What's wrong with Cmake?

One line summary:

    set(MYVAR 1234 CACHE FORCE PARENT_SCOPE)

FrancoAustrian• 9 years ago

would you recommend a book/resource to learn modern CPP from?

FlyingSnake• 9 years ago

Effective Modern C++ By Scott Meyers is good for beginners

hellofunk5• 9 years ago

Tour of C++ by the creator of C++ has been kept up to date, short, quite accessible even for a C++ beginner, but current.

con022• 9 years ago

C++ Primer, 5th Edition is good for beginners.

oblio• 9 years ago

As a non-C++ coder there are two things that "scare" me about C++ (ok, maybe not scare, but are definitely big turn offs):

- lack of a proper, cross platform, package manager: I know the history, I know that C/C++ are basically embedded in the system and they use the system package manager, but in this age it just doesn't fell right... I've been spoiled by many years of using Maven and other similar tools

- template meta-programming plus the C++ legacy features which are probably lurking in many third-party libraries (simpler languages have fewer features to abuse and even when for whatever reason you have to use a relatively subpart third-party library, you know they can't do that much damage)

There's also the compilation speed, but as far as I know there are workarounds for that.

These things are, if not unsolvable in C++, at least many years away from being available.

Maybe an experienced C++ coder can destroy my preconceptions :)

entelechy• 9 years ago

there is the https://buckaroo.pm package manager.

hellofunk5• 9 years ago

Template meta programming is unnecessary to use C++, even in its most complex of applications. It's nice if you can do it, but a lot of companies don't like developers to use TMP too much because it's not expected everyone will know or understand it. I consider it an extension to the language that is cool but not necessary for most of the work you do. It's great that it is there, and great that your compiler and library authors use it to make the tools you use very fast, but for your own code, it's just not a gripe you need to worry about.

humanrebar2• 9 years ago

Maybe an experienced C++ coder can destroy my preconceptions :)

- Generally C++ uses the OS-level package manager, like rpm or dpkg. It's not cross-platform and it doesn't have a nice interface in the source code (#include is... unfortunate), but there is a nice solution here if your organization has the discipline and tooling expertise to make it work.

- Template metaprogramming isn't bad to use at all. Everyone uses it every time they construct a vector<>. It takes a lot of skill to write, though, and unfortunately even users of TMP can end up with nasty and bloated compiler errors. Hopefully this will be addressed by "concepts" in forthcoming versions of C++, but it might be a while before that filters down to stable C++ compilers and libraries.

- The real issue that should scare you is something called "undefined behavior". It's very easy to do subtle things that cause you programs to break in weird and hard to debug ways. Nasty side effects that could theoretically include any side effect. Like saving garbage to your production database. By doing something as innocuous as overrunning an array.

https://kukuruku.co/post/undefined-behavior-and-fermats-last...

https://stackoverflow.com/questions/367633/what-are-all-the-...

There are tricks and tools to avoid undefined behavior, but I find that most C++ engineering orgs don't prioritize the tooling (linters, UB sanitizers, etc.) needed to let engineers do this productively. Consequently, a lot of writing good C++ involves detailed coding standards and/or very detail-oriented gurus poring over code reviews.

HankB99• 9 years ago

I'm a former C++ programmer (I haven't had an assignment that used C++ for years, though I pressed for a limited subset on a recent embedded system) I likely never reached the sophistication of most of the respondents here and my concerns may have been addressed.

The things that concerned me about C++ were the pitfalls that could happen due to ignorance or omission vs. errors introduced by commission. For example forgetting to implement a copy constructor for a class that allocates member data. (That results in two objects that hold pointers to the allocated data following a copy operation and if one is deleted, the other points to now deleted data.) Perhaps there are better compiler warnings or static analysis tools that will reveal problems like that today.

My other concern is how big the language has grown. I recall my excitement when I first worked with C++ since it provided direct support for a lot of things I was doing with C (Object orientation, function pointers in structs and similar) with the addition of better type safety. Nowadays many of the language features are incomprehensible and beyond my skill level. I suppose largely because I don't work with C++ on a day to day basis.

a13xb3• 9 years ago

I am a former C++ programmer who has moved on to the other languages/technologies and no longer suffer from Stockholm Syndrome.

This is just the tip of the iceberg. There are many dark corners, historic baggage, and complex interplay of language features in C++. This complexity breeds bad codebases plagued by subtle bugs created by misunderstanding of finer points of the language.

If these things scare you, run away in the other direction as fast as possible.

Teknoman117• 9 years ago

I've been wondering if if a package manager is something that should be considered part of a language or just a distribution of that language - take npm for instance. It's not a "package manager for JavaScript." It's a package manager for node.js, which is a javascript runtime environment. Python's pip was added long after the inception of the language, there are plenty of package managers for PHP, etc.

petters2• 9 years ago

lack of a proper, cross platform, package manager: I know the history, I know that C/C++ are basically embedded in the system and they use the system package manager,

I think the problem is deeper than that and that the problem could be that C++ does not have a standard ABI. It is compiler-specific. Therefore, having a system package manager does not work (as it does for C).

I compile my personal C++ codebase with four different compilers and different debug settings. The only way to manage that is to have a monorepo with all my dependencies checked in .

EricWF3• 9 years ago

If you understand the internals they're anything but pythonic. Coroutines can be a zero overhead abstraction in the some cases.

For example here is a test that verifies the optimized output for a simple (and misnamed) integer generator compiled at -O2. Notice the arguments to `print` are integer literals. (https://github.com/GorNishanov/clang/blob/Experiments/test/C...)

I'm no python expert, but I suspect C++ optimizes this code better.

yzmtf2008• 9 years ago

I think the point of being pythonic is that it's more friendly to the programmers. Bonus point if it's also optimized :)

Veedrac6• 9 years ago

C++ is one of the least Pythonic languages I know. It clashes with nearly every point on the Zen of Python[0], and C++'s "modern" libraries do nearly nothing to change that.

[0] https://www.python.org/dev/peps/pep-0020

dmix6• 9 years ago

Beautiful is better than ugly.

This one is the most apparent. Almost every example in the C++ v. Python in the article above the C++ version is notably uglier. Just look at Lambda expressions:

Python

    def adder(amount):
        return lambda x: x + amount

C++

    auto adder(int amount) {
        return [=](int x){ return x + amount; };
    }

I'm assuming [=] is used to represent Lambda here? That seems like a strange syntactic choice to me.

Edit: turns out there are various forms of Lambda (of course there wouldn't just be one in C++), for ex:

    [a, &b], [this], [=], [&], []

Depending on how the variables are captured. Capturing that additional complexity in a tight space is the cause of the ugliness here.

http://en.cppreference.com/w/cpp/language/lambda

jcelerier• 9 years ago

It clashes with nearly every point on the Zen of Python

I'd argue that C++ is more pythonic than Python. For instance:

Explicit is better than implicit.

Since when is dynamic typing more explicit than static typing ?

Errors should never pass silently.

Well guess what, with C++ they don't even pass compilation.

dis-sys• 9 years ago

Can't wait to see the libc++ coroutines to be declared as production ready. Now I am wondering whether they will be providing some channel implementation similar to the one in Golang in the future.

Interesting time for all we C++ fans.

ingve• 9 years ago

John Bandela had a great talk about that at CppCon 2016: "Channels - An alternative to callbacks and futures" [0]

[0] https://www.youtube.com/watch?v=N3CkQu39j5I

EricWF3• 9 years ago

Libc++ coroutines are production ready!

But seriously, the library implementation for coroutines is just a shallow wrapper around compiler builtins.

Therefore libc++ is probably bug free, but Clang certainly isn't.

EDIT: "probably bug free" == famous last words.

softwarelimits• 9 years ago

What would be the best learning path to take for young people wanting to learn C++ today, especially with a focus on free software? Thanks for your attention!

codebeaker• 9 years ago

Excellent question, and one for which I've not found a satisfactory answer. Perhaps some of the HN wisends can chime in. I believe with some linters (clang, etc) you can encourage your tools to slap your wrists if you code in a bad style using outdated techniques.

Cieplak5• 9 years ago

First decide if it's really something worth your time. Then, spend several years playing with the std lib and maybe dabble with Boost. Read stackoverflow threads tagged with [c++] sorting by vote count descending. Read the tests in popular github c++ projects. Read A Tour of C++. Most importantly, write and rewrite lots of code, test it, debug it, and try out cool ideas you think of. If you get stuck, context shift to another task where you're not spinning your wheels.

pjmlp9• 9 years ago

First of all, and most important one, learn C++ idioms, not C.

This means making use of library types for memory allocation, vectors and strings.

There is a place for old C style low level features, but those should come later, after the safer concepts are already ingrained.

Kate Gregory's “Stop Teaching C" talk at CppCon 2015 explains better than me.

https://www.youtube.com/watch?v=YnWhqhNdYyk

Get a nice IDE, QtCreator, Clion, VC++ Community, KDevelop, XCode.

Besides the "Tour of C++", check Stephan T. Lavavej talks at Channel 9.

"Core C++ Lectures"

https://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavav...

"Advanced STL", these ones only when you already have a good understanding of STL as user

https://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavav...

Also check video presentations from NDC, ACCU, CppCon, CppNow and C9 Going Native.

microcolonel• 9 years ago

I agree with you for everything except this one statement:

First of all, and most important one, learn C++ idioms, not C.

I think it would be better to learn both. C programming really has its place, and it gives you a model to understand how the sausage is really made. I know lots of C++ programmers who couldn't even begin to understand how half the things in their language work, this leads to completely needless performance loss (like using vectors for statically-sized arrays of data, which I recently replaced with a C array in a piece of game modelling software for a 20-30% improvement in runtime).

The fact that you consider this the most important one is outlandish. I think it's easily more important to teach the tradeoffs and models involved in things like unique_ptr, rather than creating a cargo cult for abstractions that turn out to be useless half the time.

C++ programmers really need to learn C, at least after their first year of blissful ignorance. Don't stop teaching C.

hellofunk5• 9 years ago

Get a nice IDE, QtCreator, Clion, VC++ Community, KDevelop, XCode.

No, not Xcode. Apple is not enthusiastic about c++ support and using Xcode is nice for debugging only, but write your code in something else. A lot of Mac devs will use Clion or for me, emacs, and then deploy or debug with Xcode when necessary.

Xcode doesn't format a lot of C++11 features properly and it's just a bad editor in general, even if you are using an "Apple-approved" language, which is why a lot of Swift/ObjC devs still use another JetBrains product, AppCode, for actual editing.

swah• 9 years ago

Is the Chrome source good source code to read? I always find they very organized in the high level, but don't know if its actually good C++ code.

mhh__• 9 years ago

Read lots of Scott Meyers and force yourself to read STL code. Bjarnes books are good but a bit pricey so I'd avoid paying for them.

pedrow• 9 years ago

Does anyone know, if coroutines are implemented by the compiler, will they also be available for C? Specifically, I'm thinking about the brilliant Io language which uses its own cross-platform C coroutine library. If this could be done 'natively' I wonder if it would simplify the code?

leeter• 9 years ago

They are, however I'm not sure the machinery of a coroutine will translate well to C. Gor does a pretty good breakdown of what's actually happening in this video https://www.youtube.com/watch?v=8C8NnE1Dg4A which I would suggest watching.

Not sure it can't be done, but it would require a good design. Personally I think that a libdispatch approach works better for C, particularly with the blocks extension.

kitd• 9 years ago

Simon Tatham can finally breathe easily.

nickbauman2• 9 years ago

This is how I understand the two approaches to concurrency:

1) Use preemptive system threads that can execute in parallel. A task requiring simultaneous waiting is given an operating system thread of its own so it can block without stopping the entire program. But threads require significant memory and other resources per thread. Also, the operating system can arbitrarily interleave the execution of system threads, requiring the programmer to carefully protect shared resources with locks and condition variables, which is exceedingly error-prone.

2) Have a single-threaded program, where that single thread runs an event loop whose job is to react to external events by invoking a callback function that has been registered. While it doesn't require the same kind of complex synchronization that preemptive threads do, the inverted control structure of this approach requires your own control flow to thread awkwardly through the system's event loop, leading to a maze of event callbacks.

Coroutines work with the latter style in an attempt to tame its complexity. They are themselves complex, however, and, in my opinion, that complexity doesn't pull its weight when you consider in the end you only have one thread.

Can anyone tell me what I'm missing or how these problems with these approaches have been solved in places?

snissn• 9 years ago

You can have 2) with the additional complexity / upside of multiple threads

maxpolun• 9 years ago

You can have multiple threads with coroutines. However you generally only have one thread per CPU/hardware thread, and use async io within that thread.

This is the general architecture of nginx for example (though it doesn't use coroutines, just callback based async io).

strictfp• 9 years ago

Or 3) you do like golang and erlang and build really lightweight green threads so you get the programming model of approach 1 and nearly the same speed as number 2.

This of course requires extra effort to prevent blocking of OS threads and in the case where the OS expects thread locality. But IMHO it's the superior approach.

The best solution would be if OSes themselves would provide really lightweight threads. And I suspect that they will, eventually.

nickbauman2• 9 years ago

I haven't done Erlang, but in my experience Golang has much the same problems as 1) so I'm not sure I'd agree. +1 to lightweight threads, tho.

int_19h5• 9 years ago

The problem with this approach is that as soon as you need to call out to a library written in a different language, it has no understanding of your lightweight green threads - precisely because it is currently a language/VM abstraction, not an OS abstraction, so everyone rolls their own. Furthermore, existing languages (notably, C) produce a legacy burden that'll remain even once OSes do start to add such threads.

For what it's worth, Win32 has offered a kind of green thread (fibers) for a very long time. Adoption has been minimal, even for other Microsoft products (e.g. .NET doesn't really support them properly).

KayEss• 9 years ago

The implementation of the coroutines might be complex, but their use is very straightforward -- the code looks almost exactly the same as the blocking code would, just with the awaits in there.

As for the number of threads, when I use Boost ASIO with coroutines I often end up with multiple threads servicing a pool of coroutines, so if there is shared state between them then there is still synchronisation. I use channels implemented on top of eventfd to help with that.

When I converted some network code from callbacks to coroutines the code ended up about 1/3 as long and was far simpler and easier to understand. It also fixed several bugs I simply couldn't find.

The reality is that the callbacks are far more complex to use than the coroutines.

vvanders2• 9 years ago

Yup, we used to let our designers loose on coroutines as a way to script Game AI. If designers can use them safely then I'm sure the average programmer can too :).

butterisgood• 9 years ago

Concurrency is about how you organize a solution really more than anything. Whether those concurrent tasks execute in parallel or not is a different consideration. Many authors and experts conflate these terms.

You can write concurrent code with pthreads. It may happen to execute in parallel but it doesn't have to. In fact, I believe the early SunOS/Solaris pthreads had a 'green' scheduler where it could all be done in userspace (this is from my own memory nearly 20 years ago). This made them basically "stack switchers" which is what some lightweight coroutine libraries end up doing.

Having written heavily callback-driven code. Threading contexts manually, thinking about object lifetimes, I can say that coroutines have a much cleaner flow to them and can make it easier to write and later read and debug programs than crazy callbacks and contexts.

Object lifetimes are one thing coroutines help with in a big way. I think it's why Rust is so attractive to so many.

Look at plan 9's libthread for example: https://github.com/9fans/plan9port/tree/master/src/libthread

It allows one to take advantage of nonblocking sockets as a single "kernel execution entity" mechanism across many userspace threads.

This approach works pretty well. The Mongrel2 webserver clearly borrows this approach in their task library:

https://github.com/9fans/plan9port/blob/master/src/libthread...

https://github.com/mongrel2/mongrel2/blob/master/src/task/38...

mhink• 9 years ago

Having written heavily callback-driven code. Threading contexts manually, thinking about object lifetimes, I can say that coroutines have a much cleaner flow to them and can make it easier to write and later read and debug programs than crazy callbacks and contexts.

This is the biggest reason I vastly prefer using coroutines in my Javascript projects (by way of `redux-saga` if there's heavy lifting, or just async/await otherwise).

Concurrency is about how you organize a solution really more than anything.

You hit the nail on the head here. IMHO, business logic should be expressed procedurally, whereas driver code in an event-loop driven environment (like V8) is more suited to a functional style. Coroutines let you do both, quite cleanly.

Thanks for the links, btw, I've been wanting to dig through other code like this in more established languages. :)

missblit2• 9 years ago

I found them useful when using the Boost Asio C++ networking library.

I needed to read some bytes, make a decision, read some more bytes, make another decision, etc. This started out as callback hell since every read was asynchronous, which was very painful, but after using the coroutine support I was able to write the code as if it was synchronous and the logic became a lot easier to follow.

And the coroutines weren't that hard to use, even lacking proper language support. I could basically write something like async_read(socket, buffer, yield_context);. The coroutine yielded behind the scenes and the buffer was populated once control flow was returned to the next line (from who knows where!)

CupOfJava• 9 years ago

The fundamental difference between single threading, coroutines, and multi threading:

Single Thread: 1 thread of execution, 1 execution stack

Coroutine: 1 thread of execution, multiple execution stacks

Multi threading: multiple threads of execution, multiple execution stacks

gpderetta3• 9 years ago

FYI each coroutine is normally considered its own thread of execution (which is a distinct thing from a kernel scheduled thread).

Coroutines are distinct from threads as they normally lack a scheduler (the decision to which coroutine run next is either made statically ot explicitly by the coroutine); coroutines meant to be used on top of an userspace scheduler are often called fibers (or simply userspace, or green, threads).

zackmorris• 9 years ago

I'll take a crack at this - coroutines are not about performance. They are for converting callbacks to a single thread of execution that's easier to reason about (which could themselves be embedded in other threads).

Imperative logic is equivalent to a state machine but again much easier for humans to reason about, that's why developers got so much more done in the past with synchronous execution and macros than they do today as we struggle to build even the simplest user interfaces. I'm hopeful that we can get all of the benefits of 1980s cooperative threading but that the decades of experience since allow us to avoid the pitfalls.

com2kid• 9 years ago

2) Have a single-threaded program, where that single thread runs an event loop whose job is to react to external events by invoking a callback function that has been registered. While it doesn't require the same kind of complex synchronization that preemptive threads do, the inverted control structure of this approach requires your own control flow to thread awkwardly through the system's event loop, leading to a maze of event callbacks.

Co-routines and callback based programming are great for dealing with I/O and for offloading "work" to black boxes, those black boxes can very well be other threads, CPU cores, hardware, or another computer.

When the work is complete, your callback is called, or the co-routine continues.

It is perfectly possible to be juggling multiple tasks this way, but have all the results appear in sequential order on one thread, and not have to deal with the complexity of real multi-threading.

This only works for tasks that are easily offloadable, you need VERY clean data boundaries, minimal shared state, and well defined points where you hand off control.

In other words, a well engineered program. :)

bonzini• 9 years ago

Coroutines may also require mutexes. Usually they are very coarse-grained, but the usecases for coroutine mutexes and wait queues exist. These are not pthread mutexes, of course, they would be part of the coroutine runtime or hand coded.

For example, you could have coroutines that write to a shared resource (such as a socket) where interleaving the data from two sources would be a problem.

int_19h5• 9 years ago

Event loop + callbacks allows you to fully utilize any given thread (meaning that while there's outstanding I/O or other long-running operation, the thread isn't idling waiting for it to complete, but instead performing some useful work). This is completely orthogonal to multithreading - if you have multiple threads, there's still benefit in fully utilizing them, and so each thread gets event loop and callbacks. It's true that some popular frameworks in this vein (notably, Node.js) combines event loop with single thread per process, but it's not a prerequisite. In C#, async/await is commonly used with multiple threads, for example in ASP.NET web apps.

dom0• 9 years ago

2) is concurrency, 1) is parallelism; there are various programming models for multiple threads. The basic approach of mutual exclusion (=shared memory, locks, barriers) is just one of them, another approach would be message passing / actors (queues, ZeroMQ etc.). You can mix the two, and the latter typically is implemented on top of the former, because hardware does not have message passing facilities. Some other approaches don't really fit that scheme (e.g. TBB).

Choosing an approach in this field is not always obvious, though sometimes it is. E.g. many stupid server workloads are bound on I/O concurrency, so green threads are the best fit.

However, as soon as CPU scaling is required, multiple independently schedulable kernel tasks are required -- you either have to fork/CreateProcess or spawn threads. This does not necessarily imply that larger parts of the application have to be aware of this. E.g. it's entirely possible to plug a behind-the-scenes CPU thread into an event loop.

Matthias247• 9 years ago

You can also have mixtures of those approaches in languages which support multiple threads. E.g. you could have one thread which runs an eventloop and async operations and possibly coroutines. And other threads where a pure blocking programming model is used. From these threads you could e.g. post some work to the eventloop thread and wait for it to complete.

The Future/Task abstractions that are found in multithreaded programming languages (like C# or Java) also reflect this possibilities: E.g. they allow to specify on which thread a continuation should be run instead of just assuming the current thread. They also need synchronisation internally, because multiple threads might want to use the Future object.

From my personal experience the things that work well are pure singlethreaded models with an async style (like in Javascript/node.js) or multithreaded but pure synchronous models without callbacks (as popular in Go). The mixture (multithreading with callbacks, which might be invoked on any thread) often leads to confusion how an API should be used correctly.

crudbug• 9 years ago

I think with all the async / await noise, the simplicity of co-routines is usually forgotten.

IMHO, they are the right abstraction on top of event-loops. Every major server platform, especially - JVM, CLR, should support them.

I would be very much interested in context-switch data of server applications for Threads vs. Coroutines loads.

vvanders2• 9 years ago

Yup, I never understand the need to bring a heavyweight thread to bear when coroutines are the actual semantics that most people want.

It's one of my favorite features of Lua and lets you do async-anything in a really nice and clean manner with minimal overhead.

tobz• 9 years ago

I'd say that this is roughly the case with .NET, in terms of async/await.

IIRC, you're using a thread pool under the hood, and you sort of have to opt-in: if you're trying to write your own async code, for example, you need to schedule it in a way that's slightly more complicated than just saying `go myFunc()`, but it's possible.

As for the JVM, libraries like Akka and Quasar already provide this, although possibly not as performantly as if the runtime itself provided it?

int_19h5• 9 years ago

Strictly speaking, whether you're using the thread pool under the hood or not depends on the task scheduler, which is pluggable. The default one that new threads get is indeed going to dispatch to the thread pool (on different threads at that, not the same one). But it can be pretty much anything. Async/await doesn't really care about any of that, it just creates continuations for you, and hands them over to the scheduler.

nosefouratyou• 9 years ago

I found this to be a good article about the importance of coroutines compared to continuation-passing style: http://orthecreedence.github.io/cl-async/2012/11/07/missing-...

Findeton• 9 years ago

Where can I see some examples or documentation on using coroutines in C++?

throwaway-12092• 9 years ago

I wish Google would open source / standardize their implementation of green threads ("fibers" as they're called internally). You basically write linear programs with those (with proper stack traces etc) and they're cooperatively concurrent in user space, possibly over a fixed size preemptively concurrent kernel thread pool. Very nifty and simplifies things a lot. Never seen anything like it on the outside.

Johnny_Brahms• 9 years ago

Andy Wingo's fibers for guile scheme is similar:

https://github.com/wingo/fibers/wiki/Manual

Really neat, and the implementation is really a testament to the power of delimited continuations.

anon78539737567• 9 years ago

I assume that you are trolling. Anyway, be aware that performance of Go programs are still behind of C++, so it is not a real replacement

throwaway-12092• 9 years ago

I'm not talking about Go. Google fibers are C++.

nick_• 9 years ago

Thank you for mentioning this! I've been pondering this kind of fiber+thread design for a few days and it's nice to have some validation of the idea since I didn't know of any similar designs.

Coroutines are now in Clang trunk, libc++

Related Stories