Recently, I asked what would be the execution result of the following code:
using System.Threading.Tasks; using static System.Console; class Program { static void Main() { for (var i = 0; i < 10; i++) { Task.Factory.StartNew(() => WriteLine(i)); } ReadLine(); } }
So, here it is:
At first view, it seems weird, as you may well have expected to see unique values from 0 to 9. Instead, the same value is printed out multiple times. What is going on?
We need to talk about closures
The reason why the execution result of the previous code was ten 10s on the screen lies with the closure. Are you familiar with this concept? If not, please, read this article.
The compiler will make the value of the variable i (which is in the stack) available to the lambdas capturing the local variable and placing it into a compiler-generated object on the heap. That object will be referenced inside of each lambda.
.method private hidebysig static void Main () cil managed { // Method begins at RVA 0x2050 // Code size 71 (0x47) .maxstack 3 .entrypoint .locals init ( [0] class Program/'<>c__DisplayClass0_0', [1] int32 ) // (no C# code) IL_0000: newobj instance void Program/'<>c__DisplayClass0_0'::.ctor() IL_0005: stloc.0 IL_0006: ldloc.0 // for (i = 0; i < 10; i++) IL_0007: ldc.i4.0 // (no C# code) IL_0008: stfld int32 Program/'<>c__DisplayClass0_0'::i IL_000d: br.s IL_0036 // loop start (head: IL_0036) // Task.Factory.StartNew(delegate // { // Console.WriteLine(i); // }); IL_000f: call class [System.Runtime]System.Threading.Tasks.TaskFactory [System.Runtime]System.Threading.Tasks.Task::get_Factory() IL_0014: ldloc.0 IL_0015: ldftn instance void Program/'<>c__DisplayClass0_0'::'b__0'() // (no C# code) IL_001b: newobj instance void [System.Runtime]System.Action::.ctor(object, native int) IL_0020: callvirt instance class [System.Runtime]System.Threading.Tasks.Task [System.Runtime]System.Threading.Tasks.TaskFactory::StartNew(class [System.Runtime]System.Action) IL_0025: pop IL_0026: ldloc.0 IL_0027: ldfld int32 Program/'<>c__DisplayClass0_0'::i IL_002c: stloc.1 IL_002d: ldloc.0 IL_002e: ldloc.1 // for (i = 0; i < 10; i++) IL_002f: ldc.i4.1 // (no C# code) IL_0030: add IL_0031: stfld int32 Program/'<>c__DisplayClass0_0'::i IL_0036: ldloc.0 IL_0037: ldfld int32 Program/'<>c__DisplayClass0_0'::i // for (i = 0; i < 10; i++) IL_003c: ldc.i4.s 10 IL_003e: blt.s IL_000f // end loop // Console.ReadLine(); IL_0040: call string [System.Console]System.Console::ReadLine() IL_0045: pop // (no C# code) IL_0046: ret } // end of method Program::Main
As the local variable is declared outside the loop body, the capture point is, therefore, also outside the loop body. A unique object will be instantiated! As a single object is used to store all the increments of the variable, each task will share the same closure object. Considering that the first task will start to run after the loop is completed, the value of the variable will be 10. Got it?
But, how to print out all the numbers from 0 to 9, not necessarily in order? Here is the answer:
using System.Threading.Tasks; using static System.Console; class Program { static void Main() { for (var i = 0; i < 10; i++) { var varToCapture = i; Task.Factory.StartNew(() => WriteLine(varToCapture)); } ReadLine(); } }
Now, the capturing point occurs inside the loop. In this way, a new (and different) object will be instantiated for each task.
Nice!
8 respostas
Elemar, I lost something?
This does not happen anymore since 5.0 (I guess). https://dotnetfiddle.net/ZM1Y0B.
Consider that dotnetfiddle gives you a single thread to run. Your code is not running in parallel over there.
You are may confused by this:
https://stackoverflow.com/questions/16264289/captured-closure-loop-variable-in-c-sharp-5-0
The for-loop variable is created inside the for-loop context. It is correct. But there is a single “i” variable for all *for-loop iteration* contexts. Got it?
I’ve made the same mistake and confused the for and foreach loops in the answer to your previous post.
Yeah! Makes sense 🙂 I don’t know yet how .NET Fiddle works to run in that way.
Elemar, when you say ‘Considering that the first task will start to run after the loop is completed’, there any explanation for that? Or this is a compiler behavior?
Yes. I think another greatest question here is that statement: “Considering that the first task will start to run after the loop is completed, the value of the variable will be 10.”. Why?
Is not just about the closure, the closure is ok, a variable is shared, I think that’s clear on the code. But why the first task will start to run when all the loop completed?
This is because of how the Tasks (that uses ThreadPool on background) works. The TPL will try to reuse the same Thread until you do a IO since you do not put a await keyword when creating the task. Try this for example:
Capiche?
Meu código acima saiu todo errado nos comentários.
Mas basicamente com o await ou se fizer um IO no fim do loop que se der tempo pra executar a task acima, irá executar em ordem.
Thanks for the explanation. I run some tests and it worked just like you say ?