We start them both and then wait for the first one to finish (on the line where we call TTask.WaitForAny(tasks))<\/p>\n
So what will the variable “value” hold immediately after WaitForAny returns? That should be easy. Even allowing for scheduling differences, it should be 3000.<\/p>\n
But what you may not realise is the second task is still running. If you don’t believe me, put a breakpoint on the call to Tinterlocked.Add in the second task, debug the method and then leave the ShowMessage dialog up for longer than 2 seconds (giving the second task time to finish) and your breakpoint should fire.<\/p>\n
![\"parallel](\"http:\/\/www.malcolmgroves.com\/blog\/wp-content\/uploads\/2014\/11\/parallelman1.jpg\" "\\"parallel")
<\/p>\n
This is important to understand. Depending on your app, and what you are doing in your tasks, this might matter a lot. \u00a0Let’s say we were doing something else with “value” after the call to ShowMessage. It’s possible that between the call to ShowMessage (where value was equal to 3000) and the next line where we were using it, it’s value could become 8000.<\/p>\n
So, what should we do if we don’t want this to happen?<\/p>\n
Firstly, after WaitForAny returns, we should cancel the other tasks. Some code like the following will loop through all the tasks, cancelling any that have not completed.<\/p>\n
TTask.WaitForAny(tasks);\r\n for LTask in tasks do\r\n LTask.Cancel;\r\n ShowMessage ('All done: ' + value.ToString);<\/pre>\nwhere LTask is just a local variable\u00a0of type ITask.<\/p>\n
That’s a good start, but calling Cancel on a Task doesn’t actually cancel the task. That might sound a little odd at first, but all you are really doing is signalling to the task that it should cancel itself. It’s up to the logic inside the anonymous method you pass the task to check for this status.<\/p>\n
When should you check it? Depends on what you’re doing, but there are a few likely places:<\/p>\n
- \n
- Right at the start of your Task. Remember, you might have tasks that have not yet started, due to waiting for threads to become available in the Thread Pool, so if they have been cancelled before they have even started, may as well find that out early and get out before doing any work.<\/li>\n
- If the task is long running, you might check it at regular intervals, so you can bail out and stop any time- or resource-consuming activity as early as possible. Let’s say you are in a loop, you might check it every time around the loop, or every x times around the loop, depending on the work you are doing.<\/li>\n
- While the above two might be optional in your app, I’d say this one is mandatory. In my opinion you should absolutely check it before you make any changes outside your task, like updating the UI or in this case, writing back to the “value” variable, like so:<\/li>\n<\/ul>\n
sleep (5000); \/\/ 5 seconds\r\n if tasks[1].Status <> TTaskStatus.Canceled then\r\n TInterlocked.Add (value, 5000);<\/pre>\n
So here’s what my revised code looks like in total:<\/p>\n
procedure TFormThreading.Button2Click(Sender: TObject);\r\nvar\r\n tasks: array of ITask;\r\n value: Integer;\r\n LTask: ITask;\r\nbegin\r\n Setlength (tasks ,2);\r\n value := 0;\r\n\r\n tasks[0] := TTask.Create(procedure\r\n begin\r\n sleep (3000);\r\n if tasks[0].Status <> TTaskStatus.Canceled then\r\n TInterlocked.Add(value, 3000);\r\n end);\r\n tasks[0].Start;\r\n\r\n tasks[1] := TTask.Create(procedure\r\n begin\r\n sleep (5000);\r\n if tasks[1].Status <> TTaskStatus.Canceled then\r\n TInterlocked.Add (value, 5000);\r\n end);\r\n tasks[1].Start;\r\n\r\n TTask.WaitForAny(tasks);\r\n for LTask in tasks do\r\n LTask.Cancel;\r\n ShowMessage('All done: ' + value.ToString);\r\nend;<\/pre>\n<\/p>\n
My main point with this post was to highlight that Tasks continue on, even if you’re not waiting for them anymore, so checking for the Cancelled flag and ending your tasks as soon as possible is a good thing. However, we’re not quite done here. There is still a potential race condition in this code<\/strong>, which I’ll resolve in the next post<\/a>.<\/p>\n
If you’re looking for more details on the PPL, including some meatier examples, check out Danny Wind<\/a>‘s CodeRage 9 session, and stay all the way to the end.<\/p>\n