Spot the Bug: Fun Concurrency Bug

[Chris Mullins [MVP - C#]]

I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthre ads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate ()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins

[Peter Duniho]

Chris Mullins [MVP - C#] wrote:

I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

Define "bug".

Assuming your main thread doesn't get preempted while creating the
threads, both threads are going to fail the assertion. And since the
main thread is doing so little, it is in fact likely to get all the way
to the first call to Join() before another thread gets to run.

But is that a bug? The Debug class is thread-safe, so having two
threads concurrent fail an assertion shouldn't cause a problem in and of
itself.

Pete

[Nicholas Paldino [.NET/C# MVP]]

Even though it does deal with concurrency, I wouldn't file this under a
concurrency issue, per se. The error comes from using an anonymous method
in the loop and capturing the variable "i".

Because it is used in the anonymous method (and there is only one
instance of it created), when the loop exits, i is equal to 2. Not all the
threads have started up by this point, and then by the time that they do,
the assertion fails.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Chris Mullins [MVP - C#]" <cm******@yahoo .comwrote in message
news:e6******** ******@TK2MSFTN GP02.phx.gbl...

>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthre ads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate ()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins

[John Duval]

On Oct 24, 2:19 pm, "Chris Mullins [MVP - C#]" <cmull...@yahoo .com>
wrote:

I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthre ads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate ()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);

}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins

Hi Chris,
It looks like you're incrementing i to 2 before the threads start.
You can see the same thing with one thread and no anonymous delegate:

private static int _global;
public static void Main()
{
_global = 1;
Thread t = new Thread(MyThread Proc);
t.Start();

_global = 2;
t.Join();
}

public static void MyThreadProc()
{
Debug.Assert(_g lobal != 2);
}

[Chris Mullins [MVP - C#]]

It's not a .Net bug or anything like that, but it's certainly a bug in the
sense that "my code doesn't do what I wrote it to do" sense.

The convergence of technology that caused this to happen made for a weird
debugging process. When you run it in the debugger, it works just fine (as
do most race conditions). Inspecting all the variables always shows the
correct results, etc.

I've seen many people do thing like this with Closures, and the fact that
the passed variable changes makes the code very strange to follow...

It was also confusing, as I *expected* the variable passed into the closure
to be passed by value (it's an int, afterall). I expected to get the same
behavior as if I had passed in a constant. The fact that C# boxed the
variable, passed in a reference to it, and then later checked it after the
for-loop had completed (and the original variable was out of scope) and got
the "illegal" variable, really was amusing...

--
Chris

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:et******** ******@TK2MSFTN GP04.phx.gbl...

Even though it does deal with concurrency, I wouldn't file this under a
concurrency issue, per se. The error comes from using an anonymous method
in the loop and capturing the variable "i".

Because it is used in the anonymous method (and there is only one
instance of it created), when the loop exits, i is equal to 2. Not all
the threads have started up by this point, and then by the time that they
do, the assertion fails.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Chris Mullins [MVP - C#]" <cm******@yahoo .comwrote in message
news:e6******** ******@TK2MSFTN GP02.phx.gbl...

>>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthr eads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate ()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

--
Chris Mullins

[Chris Mullins [MVP - C#]]

Well, it's a bug in that the code doesn't do what was originally intended.
Instead an "impossible " assertion fires, and the developer(s) get a very
confused look on their faces for a few minutes...

Your explination is dead on, but the boxing / byref behavior of the variable
passed into the Closure is what made this code behavie in a way other than
was expected. I was expecting the int (a value type) to be passed in by
value, and therefore not change...

--
Chris Mullins

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:13******** *****@corp.supe rnews.com...

Chris Mullins [MVP - C#] wrote:

>I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

Define "bug".

Assuming your main thread doesn't get preempted while creating the
threads, both threads are going to fail the assertion. And since the main
thread is doing so little, it is in fact likely to get all the way to the
first call to Join() before another thread gets to run.

But is that a bug? The Debug class is thread-safe, so having two threads
concurrent fail an assertion shouldn't cause a problem in and of itself.

Pete

[Peter Duniho]

Chris Mullins [MVP - C#] wrote:

[...]
It was also confusing, as I *expected* the variable passed into the closure
to be passed by value (it's an int, afterall). I expected to get the same
behavior as if I had passed in a constant. The fact that C# boxed the
variable, passed in a reference to it, and then later checked it after the
for-loop had completed (and the original variable was out of scope) and got
the "illegal" variable, really was amusing...

Maybe someone who has more intimate knowledge can comment, but AFAIK
this isn't a case of the value type being boxed. If it were, you
wouldn't have had the problem, since the boxing still preserves the
value as it was at the moment of boxing, not referencing the variable
itself.

Rather, by capturing the variable in the anonymous method, what is being
used in the method is the variable itself. That's why any change to the
variable that happens before the code that uses it is executed is seen
when that code is executed.

The key here is the "capturing" behavior, and I believe that has nothing
to do with boxing.

I think the variable capturing that happens with anonymous methods is
pretty cool, actually. But I agree it can lead to some non-obvious
results when one is not aware that the capturing is going on, and what
the capturing does.

Pete

[Peter Duniho]

Chris Mullins [MVP - C#] wrote:

Well, it's a bug in that the code doesn't do what was originally intended.
Instead an "impossible " assertion fires, and the developer(s) get a very
confused look on their faces for a few minutes...

I'm glad you put "impossible " in quotes. :)

Your explination is dead on, but the boxing / byref behavior of the variable
passed into the Closure is what made this code behavie in a way other than
was expected. I was expecting the int (a value type) to be passed in by
value, and therefore not change...

I think my other post elaborates on this already, but I think it's
important to note that not only is there no boxing, I don't think it's
actually that the variable is being "passed" either. So it's not really
correct to talk about the variable be passed by reference or by value.
It's captured, not passed.

If you did want the value passed by value, you could have achieved that
by using the ParameterizedTh readStart constructor for the Thread
instances, and a delegate that actually does have a parameter. Then you
could literally pass the loop variable in by value and have things work
as you expected.

None of this is meant to downplay the potential for confusion here. I
agree that it can be confusing, if you're not familiar with the variable
capturing behavior. I have the benefit of having already been surprised
by this months ago and having Jon Skeet explain it here in this
newsgroup. :)

Pete

[Nicholas Paldino [.NET/C# MVP]]

Peter and Chris,

There is no boxing here. What is going on here is that the compiler is
generating a class which has a public field "i" which also contains the
method which is passed to the thread for the delegate.

The field is of the same type as the variable, in this case, an int,
which means no boxing occurs.

The reason that it asserts is mentioned in my first post. Because the
scope of i actually contains the loop, there is one instance of the
anonymous class created for the delegate, for all iterations of the loop.

To have a separate instance created every time, you can replace the code
with the following:

List<Threadthre ads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
// Reassign i to prevent a shared anonymous method implementation.
int x = i;

Thread t = new Thread(delegate ()
{
Debug.Assert(x != 2);
});

t.Start();
threads.Add(t);
}

In the code above, a new instance of the anonymous class will be created
on each iteration through the loop and then assigned to the delegate.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:13******** *****@corp.supe rnews.com...

Chris Mullins [MVP - C#] wrote:

>[...]
It was also confusing, as I *expected* the variable passed into the
closure to be passed by value (it's an int, afterall). I expected to get
the same behavior as if I had passed in a constant. The fact that C#
boxed the variable, passed in a reference to it, and then later checked
it after the for-loop had completed (and the original variable was out of
scope) and got the "illegal" variable, really was amusing...

Maybe someone who has more intimate knowledge can comment, but AFAIK this
isn't a case of the value type being boxed. If it were, you wouldn't have
had the problem, since the boxing still preserves the value as it was at
the moment of boxing, not referencing the variable itself.

Rather, by capturing the variable in the anonymous method, what is being
used in the method is the variable itself. That's why any change to the
variable that happens before the code that uses it is executed is seen
when that code is executed.

The key here is the "capturing" behavior, and I believe that has nothing
to do with boxing.

I think the variable capturing that happens with anonymous methods is
pretty cool, actually. But I agree it can lead to some non-obvious
results when one is not aware that the capturing is going on, and what the
capturing does.

Pete

[Jon Skeet [C# MVP]]

Chris Mullins [MVP - C#] <cm******@yahoo .comwrote:

I hit this bug last night in some test code I had written. It took a few
minutes to figure out what the root cause was, and it left me thinking,
"Wow. That was an interesting one that doesn't come up very often!".

So, for fun, who sees the bug and can explain why it's happening?

List<Threadthre ads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(delegate ()
{
Debug.Assert(i != 2);
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

Posting without reading any responses... "i" is captured and only has a
single "instance", so the assertion will fail if the thread executes
after the loop has "finished".

The solution:

List<Threadthre ads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
int j=i; // THIS IS THE CHANGE
Thread t = new Thread(delegate ()
{
Debug.Assert(j != 2); // AND THIS
});

t.Start();
threads.Add(t);
}

foreach (Thread thread in threads)
thread.Join();

There's a new instance of "j" each time we go round the loop.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too