Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Sounds like boost::async
Posted Aug 16, 2013 14:44 UTC (Fri) by chrisV (subscriber, #43417)
Excellent. Although I suspect "fairly trivial" may not be so trivial when doing it in a multi-threaded context: it might require in effect writing an entire VM. If you could put forward a boost proposal with outline implementation I suspect it would be well received.
Posted Aug 16, 2013 16:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
But I cheated a little bit because I know about await/async implementation based on Boost.Coroutine: https://github.com/panaseleus/await_emu (originally from here: http://www.rsdn.ru/forum/cpp/5219587.flat#5219587 )
Posted Aug 16, 2013 16:26 UTC (Fri) by elanthis (guest, #6227)
The idea received very favorable feedback at the committee meeting I was at. My only complaints I raised were that the implementation provides no support for allocators or user-controlled allocation of task data, which is a problem for people needing very tight memory control or specialized debugging interfaces (e.g games, others).
Posted Aug 16, 2013 16:53 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
The only major thing missing is composite stack - ability to grow stack on demand, like in Go.
Posted Aug 22, 2013 16:36 UTC (Thu) by tvld (subscriber, #59052)
That was definitely _not_ my impression at the ISO C++ meetings I attended. What I observed was most people not commenting, some liked it, and some disliked it.
While await (i.e., "resumable" functions) makes concurrency _look_ less complex, it's still concurrent execution even if it may look like a sequential program.
If you look at the proposal closely, there are several open issues or unanswered questions (e.g., which properties do the execution agents have precisely? how much of a light-weight thread are they?). Second, there's no detailed discussion of why this should come in exactly this form, including having to annotate functions; there are high-level remarks about C# etc. having it, and that some of the design's properties are necessary because of certain unnamed implementation concerns, but there's no discussion at all about the implementation trade-offs.
I'm mentioning the implementation aspect because besides making concurrency look less scary, this is clearly driven by performance concerns: There can be blocking which they want to avoid (thus, add concurrency), yet they don't want to pay the price of full OS threads (e.g., ordinary stacks, thread-local storage). Thus, await gives you lighter-weight execution agents (again, they don't specify the details, but that's how I understood the answers of the proposal's authors).
So, overall I think it's necessary to think about to which extent standardized light-weight execution agents would be sufficient. (Note that there might be implemented similar to green threads, but unlike traditional green threads or M:N threading those execution agents don't have to pretend that the green thread is a true OS thread, so they have to do significantly less). If they are sufficient, then one probably doesn't need to burden programmers with littering their code with function annotations and await keywords, nor require them to specify all the points where cooperative scheduling can take place.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds