tag:blogger.com,1999:blog-5359546512544809971.post414629047316829395..comments2024-03-22T10:42:37.237-07:00Comments on Jeremy Bytes: BackgroundWorker Component Compared to .NET TasksJeremyhttp://www.blogger.com/profile/06749690234470413216noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-5359546512544809971.post-580519089025542782015-10-22T22:18:34.397-07:002015-10-22T22:18:34.397-07:00I'm not sure what the differences are in perfo...I'm not sure what the differences are in performance. The BackgroundWorker component is more-or-less a facade around a thread pool thread while using Task creates a state machine. So there are bound to be some differences there. I would not be concerned about creation vs. re-use unless you have 100s or 1000s of instances that you're working with.<br /><br />One thing to keep in mind is that the BackgroundWorker component can only do one thing at a time. So if you have an event that calls RunWorkerAsync before the previous process has finished, you'll get an exception. Task is much more powerful and flexible. BackgroundWorker is easy to use. Each has it's pros and cons.<br /><br />For more information on Tasks, you can check here for some articles as well as a video series: http://www.jeremybytes.com/Downloads.aspx#TasksJeremyhttps://www.blogger.com/profile/06749690234470413216noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-4094378055204702382015-10-22T14:43:17.352-07:002015-10-22T14:43:17.352-07:00How is the performance ? Task - is that a create e...How is the performance ? Task - is that a create every time I need it mechanism , or can I have it hang around .. the BackGroundWorker I can reuse over and over what is the cost one versus the other performance wise? For example on such an event I get every second should I Task.Run(() => MyProcess()); or RunWorkerAsync - who is faster ?stixhttps://www.blogger.com/profile/12139802254056335247noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-34496477271865235942015-07-21T10:39:10.191-07:002015-07-21T10:39:10.191-07:00Yes, there is a very important reason that "T...Yes, there is a very important reason that "ThrowIfCancellationRequested" is inside the foreach loop. When we call "Cancel" on our CancellationTokenSource, it sets the token to a "canceled" state, but this is merely a flag. It is up to us to check the status of the token.<br /><br />When we call "ThrowIfCancellationRequested", this checks the state of our token. If the token is in a canceled state, it throws the exception; otherwise this method does nothing. By doing this inside our foreach block, we check the token on each iteration of our loop. If it finds the token in a canceled state, then it will throw the exception and short-circuits the process.<br /><br />If you want a little more about canceling tasks (but without a loop), you can check out this article: <a href="http://jeremybytes.blogspot.com/2015/01/task-and-await-basic-cancellation.html" rel="nofollow">Task and Await: Basic Cancellation</a>.Jeremyhttps://www.blogger.com/profile/06749690234470413216noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-26091457348534819412015-07-21T10:00:52.483-07:002015-07-21T10:00:52.483-07:00Jeremy,
Is there a reason the cancelToken.ThrowIf...Jeremy,<br /><br />Is there a reason the cancelToken.ThrowIfCancellationRequested(); is inside the foreach loop in the DoWorkAsync()? Seems to me it could go above the foreach and only get executed once unless there is something with threading I haven't grasped yet.<br /><br />dbl<br />dblhttps://www.blogger.com/profile/10375711433171466162noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-72302283548940571202015-05-23T05:13:34.347-07:002015-05-23T05:13:34.347-07:00This code would stop the processing; however, it w...This code would stop the processing; however, it would not put the Task into a canceled state. This is important because we usually treat a canceled task differently than a completed task. When we use "ThrowIfCancellationRequested", then we can check the state of the task and continue our application as appropriate. For more information, see "Task and Await: Basic Cancellation" (http://jeremybytes.blogspot.com/2015/01/task-and-await-basic-cancellation.html).Jeremyhttps://www.blogger.com/profile/06749690234470413216noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-54161589582890969302015-05-22T23:09:24.068-07:002015-05-22T23:09:24.068-07:00why can't you do this in your for loop
if(can...why can't you do this in your for loop<br /><br />if(cancelToken.IsCancellationRequested) <br /> break;TJoneshttps://www.blogger.com/profile/05670709208507628807noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-91357801332732601432014-04-27T12:27:14.977-07:002014-04-27T12:27:14.977-07:00Thanks Jeremy,
Yes, I re-ran your example "a...Thanks Jeremy,<br /><br />Yes, I re-ran your example "as is', not an debugging mode and the Cancel request worked as expected.<br /><br />-MichaelAnonymoushttps://www.blogger.com/profile/03414334869215522068noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-82972989226098685122014-04-27T08:22:01.675-07:002014-04-27T08:22:01.675-07:00Hi, Michael,
It's not quite correct that clic...Hi, Michael,<br /><br />It's not quite correct that clicking the Cancel button causes an unhandled exception. Yes, when we call "cancelToken.ThrowIfCancellationRequested()" it does throw an exception. But this exception is automatically handled by the Task infrastructure, so we do not need to handle this exception ourselves.<br /><br />If we run the sample with debugging, then the debugger stops on the exception, but we can continue running the application from there without problems. And if we run the sample *without* debugging, we see that there is no unhandled exception since Task takes care of it for us. The reason that we call this "Throw.." method is because this is what sets "Task.IsCanceled" to true.<br /><br />So, yes it does throw an exception, but it is not an unhandled exception. (I don't really like the idea of throwing an exception here, either. But this is the way that the Task Parallel Library was written.)<br /><br />-JeremyJeremyhttps://www.blogger.com/profile/06749690234470413216noreply@blogger.comtag:blogger.com,1999:blog-5359546512544809971.post-11528683244533654082014-04-27T06:35:03.336-07:002014-04-27T06:35:03.336-07:00Thank you Jeremy for providing your blog and compa...Thank you Jeremy for providing your blog and comparison examples.<br /><br />In the TaskWithProcess project, clicking on the Cancel button cause an unhandled exception to be thrown.<br /><br />How to we get the Task's status to equal "IsCanceled" ? (Task in a cancelled state)<br /><br />I was able to provide a work-around or hack, by references the "Token" value but that requires changes to your original design.<br /><br />Snippet:<br /> if (_cancelTokenSource.Token.IsCancellationRequested || task.IsCanceled)<br /> {<br /> Output = "Canceled";<br /> } <br /> else<br /> if (task.IsFaulted)<br /> {<br /> // Handle exception state<br /> }<br /><br /><br />Regards,<br />MichaelAnonymoushttps://www.blogger.com/profile/03414334869215522068noreply@blogger.com