tag:blogger.com,1999:blog-7101933101966798446.post5582323733752410795..comments2024-03-17T08:14:57.577-07:00Comments on The View from Aristeia: Draft TOC for EC++11 Concurrency ChapterScott Meyershttp://www.blogger.com/profile/05280964633768289328noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-7101933101966798446.post-78724934612308175912013-04-11T18:12:13.258-07:002013-04-11T18:12:13.258-07:00@Michael Marcin: "Nullary functions" wou...@Michael Marcin: "Nullary functions" would be fine, but I don't think "parameterless functions" is incorrect, and I think it's likely to be understood by more people.Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-20336828100744428122013-04-11T18:02:03.968-07:002013-04-11T18:02:03.968-07:00Shouldn't
Pass parameterless functions to...
...Shouldn't<br /><br />Pass parameterless functions to...<br /><br />be<br /><br />Pass nullary functions to...Michael Marcinhttps://www.blogger.com/profile/14917675779712267843noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-3970985848011246862013-04-07T09:20:55.574-07:002013-04-07T09:20:55.574-07:00@Markus For actors in C++11 see libcppa.blogspot.c...@Markus For actors in C++11 see libcppa.blogspot.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-19342463672703134722013-04-07T09:12:37.908-07:002013-04-07T09:12:37.908-07:00I'm a bit uncertain about the first topic of t...I'm a bit uncertain about the first topic of tasks vs. threads. I see this come up often, and it seems to somewhat ignore what I feel are two very distinct classes of concurrency. The first one you are hinting at is processing based concurrency where you use another thread to complete some package of work.<br /><br />The second one is service based concurrency. You have a service which continually runs and is waiting to be instructed what to do (for example an audio device). The "task" model doesn't apply well to these: instead you create messages and tell them things they should do.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-90537338075161440422013-04-06T10:17:26.873-07:002013-04-06T10:17:26.873-07:00@Anonymouse: If there are no paths (including due ...@Anonymouse: If there are no paths (including due to exceptions, breaks, continues, premature returns, flowing off the end of the function, etc.) where a joinable thread is destroyed, then the code adheres to the guideline. Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-78497838873235179532013-04-06T10:12:05.817-07:002013-04-06T10:12:05.817-07:00But those unwanted std::terminate calls are bugs t...But those unwanted std::terminate calls are bugs that get caught really early in development. Is there anything more complex about that behavior besides the join/detach/move? Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-59698059735314014092013-04-06T09:52:55.367-07:002013-04-06T09:52:55.367-07:00@Unknown and @Norbert Wenzel: The motivation for t...@Unknown and @Norbert Wenzel: The motivation for the guideline is that if a joinable thread has its destructor called, std::terminate is invoked. Threads are most commonly made unjoinable via a join, detach, or std::move to another std::thread object. The challenge is to make sure that one of these things happens on every path out of a block.Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-37315291821247332082013-04-06T06:55:37.068-07:002013-04-06T06:55:37.068-07:00I too wonder about the "Make std::threads unj...I too wonder about the "Make std::threads unjoinable on all paths" item. My advice has been to avoid detached threads, and this looks like it will run counter to that advice.<br /><br />A lot of code that I write needs to live in shared libraries / DLLs. If my library creates a thread, it needs to be able to control the lifetime of that thread. If it doesn't control the lifetime of that thread, then when my DLL gets unloaded, bad things happen.Ben Craighttps://www.blogger.com/profile/01237025391218848306noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-41346714240062717842013-04-06T00:52:40.500-07:002013-04-06T00:52:40.500-07:00Looking forward to that book. And I'm especial...Looking forward to that book. And I'm especially curious about "Make std::threads unjoinable on all paths.". I honestly have no idea from the topic what will be in there and why.<br /><br />One good reason (more) to buy that book when it's published.Norbert Wenzelnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-23167421993232360552013-04-05T13:04:53.283-07:002013-04-05T13:04:53.283-07:00Looks great. I really liked your older C++ books.
...Looks great. I really liked your older C++ books.<br />Looking forward to the C++11 version.<br /><br />I agree about tasks instead of threads.<br />When I write Java or Scala code (I do mostly Java/Scala now) I try to avoid creating specific threads.<br />It is almost always better to have independent tasks that don't share anything. This avoids a lot of concurrency problems.<br />An actor based approach (like www.akka.io) is also great. I hope actors can make it into the C++ standard one day.<br />Intel's Threading Building Blocks for C++ also help to use tasks instead of threads.<br /><br />MarkusMarkus Jaishttp://www.markusjais.comnoreply@blogger.com