How can I capture the value of an outer variable inside a lambda expression?

15,027

Solution 1

This has more to do with lambdas than threading. A lambda captures the reference to a variable, not the variable's value. This means that when you try to use i in your code, its value will be whatever was stored in i last.

To avoid this, you should copy the variable's value to a local variable when the lambda starts. The problem is, starting a task has overhead and the first copy may be executed only after the loop finishes. The following code will also fail

for (var i = 0; i < 50; ++i) {
    Task.Factory.StartNew(() => {
        var i1=i;
        Debug.Print("Error: " + i1.ToString());
    });
}

As James Manning noted, you can add a variable local to the loop and copy the loop variable there. This way you are creating 50 different variables to hold the value of the loop variable, but at least you get the expected result. The problem is, you do get a lot of additional allocations.

for (var i = 0; i < 50; ++i) {
    var i1=i;
    Task.Factory.StartNew(() => {
        Debug.Print("Error: " + i1.ToString());
    });
}

The best solution is to pass the loop parameter as a state parameter:

for (var i = 0; i < 50; ++i) {
    Task.Factory.StartNew(o => {
        var i1=(int)o;
        Debug.Print("Error: " + i1.ToString());
    }, i);
}

Using a state parameter results in fewer allocations. Looking at the decompiled code:

  • the second snippet will create 50 closures and 50 delegates
  • the third snippet will create 50 boxed ints but only a single delegate

Solution 2

That's because you are running the code in a new thread, and the main thread immediately goes on to change the variable. If the lambda expression were executed immediately, the entire point of using a task would be lost.

The thread doesn't get its own copy of the variable at the time the task is created, all the tasks use the same variable (which actually is stored in the closure for the method, it's not a local variable).

Solution 3

Lambda expressions do capture not the value of the outer variable but a reference to it. That is the reason why you do see 50 or After in your tasks.

To solve this create before your lambda expression a copy of it to capture it by value.

This unfortunate behaviour will be fixed by the C# compiler with .NET 4.5 until then you need to live with this oddity.

Example:

    List<Action> acc = new List<Action>();
    for (int i = 0; i < 10; i++)
    {
        int tmp = i;
        acc.Add(() => { Console.WriteLine(tmp); });
    }

    acc.ForEach(x => x());

Solution 4

Lambda expressions are by definition lazily evaluated so they will not be evaluated until actually called. In your case by the task execution. If you close over a local in your lambda expression the state of the local at the time of execution will be reflected. Which is what you see. You can take advantage of this. E.g. your for loop really don't need a new lambda for every iteration assuming for the sake of the example that the described result was what you intended you could write

var i =0;
Action<int> action = () => Debug.Print("Error: " + i);
for(;i<50;+i){
    Task.Factory.StartNew(action);
}

on the other hand if you wished that it actually printed "Error: 1"..."Error 50" you could change the above to

var i =0;
Func<Action<int>> action = (x) => { return () => Debug.Print("Error: " + x);}
for(;i<50;+i){
    Task.Factory.StartNew(action(i));
}

The first closes over i and will use the state of i at the time the Action is executed and the state is often going to be the state after the loop finishes. In the latter case i is evaluated eagerly because it's passed as an argument to a function. This function then returns an Action<int> which is passed to StartNew.

So the design decision makes both lazily evaluation and eager evaluation possible. Lazily because locals are closed over and eagerly because you can force locals to be executed by passing them as an argument or as shown below declaring another local with a shorter scope

for (var i = 0; i < 50; ++i) {
    var j = i;
    Task.Factory.StartNew(() => Debug.Print("Error: " + j));
}

All the above is general for Lambdas. In the specific case of StartNew there's actually an overload that does what the second example does so that can be simplified to

var i =0;
Action<object> action = (x) => Debug.Print("Error: " + x);}
for(;i<50;+i){
    Task.Factory.StartNew(action,i);
}
Share:
15,027
Erwin Mayer
Author by

Erwin Mayer

I am happy! SOreadytohelp

Updated on June 05, 2022

Comments

  • Erwin Mayer
    Erwin Mayer almost 2 years

    I just encountered the following behavior:

    for (var i = 0; i < 50; ++i) {
        Task.Factory.StartNew(() => {
            Debug.Print("Error: " + i.ToString());
        });
    }
    

    Will result in a series of "Error: x", where most of the x are equal to 50.

    Similarly:

    var a = "Before";
    var task = new Task(() => Debug.Print("Using value: " + a));
    a = "After";
    task.Start();
    

    Will result in "Using value: After".

    This clearly means that the concatenation in the lambda expression does not occur immediately. How is it possible to use a copy of the outer variable in the lambda expression, at the time the expression is declared? The following will not work better (which is not necessarily incoherent, I admit):

    var a = "Before";
    var task = new Task(() => {
        var a2 = a;
        Debug.Print("Using value: " + a2);
    });
    a = "After";
    task.Start();
    
  • Erwin Mayer
    Erwin Mayer almost 12 years
    Do you mean creating a copy in the lambda expression will work? Currently it doesnt: Using var a2 = a; Logging.Print("Using value: " + a2); still retruns "Using value: After".
  • Alois Kraus
    Alois Kraus almost 12 years
    Sorry. You need to place the copy outside the lambda to make it work.
  • Ivan Golović
    Ivan Golović almost 12 years
    The situation is quite known, it is described here: blogs.msdn.com/b/ericlippert/archive/2009/11/12/…
  • James Manning
    James Manning almost 12 years
    For the first loop, the 'right' fix (AFAICT) is to do the var i1 = i; inside the loop but before the Task.Factory.StartNew. With that change, each closure will refer to its own separate variable and you'll get the right effect. The state parameter avoids the need for the closure, though, so certainly more efficient, but not necessary if you just want the correct behavior.
  • Panagiotis Kanavos
    Panagiotis Kanavos almost 12 years
    It's not that it doesn't work (that's the way the language works), it's that the lambdas may only start execution only AFTER the loop finishes
  • Panagiotis Kanavos
    Panagiotis Kanavos almost 12 years
    @James Manning, you are right, this creates a variable local to the loop only so there is no chance of capturing the wrong variable
  • James Manning
    James Manning almost 12 years
    @PanagiotisKanavos - based on Erwin's comment, if you change the first code chunk to make that change, it sounds like he'll accept it as the answer.
  • svick
    svick almost 12 years
    Both your solutions will result in the same number of allocations: in the first case, it's 50 closure objects, and in the second case it's 50 boxed ints. So I'm not so sure the second one will be more efficient.
  • Panagiotis Kanavos
    Panagiotis Kanavos almost 12 years
    The compiler creates more than one object per capture. This is described by Stephen Toub at blogs.msdn.com/b/pfxteam/archive/2012/02/03/10263921.aspx
  • Panagiotis Kanavos
    Panagiotis Kanavos almost 12 years
    After looking at decompiled code for both cases, the code with captures generates 50 closure and 50 delegates while the code using object state will create 50 boxed ints and ONLY a single action delegate.
  • svick
    svick about 11 years
    BTW, that lambda ca be simplified to x => () => Debug.Print("Error: " + x).
  • Sotirios Delimanolis
    Sotirios Delimanolis over 8 years
    For the object state example, there might only be one action delegate, but doesn't the implementation, internally, have to create a new object to store that state so that it can pass it once the action is invoked?
  • Shannon
    Shannon over 3 years
    @SotiriosDelimanolis Yes the task has to allocate space to store the state parameter
  • Jan Suchotzki
    Jan Suchotzki over 3 years
    If somebody still cares about the great article from Eric Lippert, referenced by @IvanG here it is: ericlippert.com/2009/11/12/…