Jon,

I do not understand much of threading & was curious
So, I ran this using snippet compiler & couldn't see any difference in
output

<code>
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading;

class Sample
{
public static void Main(string[] args)
{
List<Thread> threads = new List<Thread>();
for (int i = 0; i < 2; i++)
{
int j = i;
Thread t = new Thread(delegate()
{
Console.WriteLine("inside thread: " + j);
Debug.Assert(j != 2);
});

Console.WriteLine("starting thread: " + i);
t.Start();
threads.Add(t);

}

foreach (Thread thread in threads)
thread.Join();
}
}
</code>

Could you explain, what is the problem with having to introduce j as a
temp. variable?
What is the problem with the original code (without introduction of
temp. variable inside the loop)?

Thanks
Kalpesh


On Oct 24, 12:28 pm, Jon Skeet [C# MVP] <sk... (AT) pobox (DOT) com> wrote:

"Jon Skeet [C# MVP]" <skeet (AT) pobox (DOT) com> wrote

Or:
for (int i = 0; i < 2; i++)
{
Thread t = new Thread((ParameterizedThreadStart)delegate(object
y){ Debug.Assert((int)y != 2); });
t.Start(i);
threads.Add(t);
}

Or in C# V3 :
for (int i = 0; i < 2; i++)
{
Thread t = new Thread(y => { Debug.Assert((int)y != 2); });
t.Start(i);
threads.Add(t);
}


Willy.

Kalpesh wrote:
I don't think there's a problem introducing j as a temporary variable.
It's a nice solution to the problem.

The issue has to do with the order in which the code is executed and
what value each variable holds. The code you posted is likely (but not
guaranteed) to output something like this:

starting thread: 0
starting thread: 1
inside thread: 0
inside thread: 1

However, if you remove the local j variable, and in the anonymous method
just use i, you would get something like this:

starting thread: 0
starting thread: 1
inside thread: 2
inside thread: 2

Again, no guarantees due to thread scheduling, but it's a likely
outcome. And of course, the assertion would fail so in addition to the
output, you'd get that as well.

Hope that helps.

Pete

Pete,

Thanks for your reply.
Pardon my ignorance - but it outputs the same thing on the machine
that I am on.

If that's the case, how to really see them outputting different
results (in order to produce the bug)?
Also, in real life case -how to make sure that problems like this dont
pass by & get caught when in production?

Thanks
Kalpesh

Kalpesh <shahkalpesh (AT) gmail (DOT) com> wrote:

<snip>

It's not really a concurrency issue - it's an anonymous method issue.
The two new threads (and the continuing method) are all still using the
same variable.

See http://pobox.com/~skeet/csharp/csharp2/delegates.html for more -
look at the last section (captured variables)

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Kalpesh wrote:
What outputs the same thing? What is the actual output? For which
version of the code?

The easiest thing would be to include a call to Thread.Sleep() at the
beginning of the anonymous method, to ensure that the rest of the code
in the anonymous method doesn't execute until the main thread has
finished initializing all of the threads.

An alternative would be to use an additional loop. Currently the code
has two: one initializes and starts each thread, while the second waits
for each to complete. You could break the first loop into two different
loops, one of which initializes each thread, another to actually start
each thread. That would reproduce the problem reliably as well.

Well, as a start: very VERY suspicious any time you use a variable
inside an anonymous method that was declared outside that anonymous
method, and the anonymous method is going to be executed asynchronously
relative to the code that's declaring the anonymous method.

The most common reasons for using an anonymous method involve it being
executed asynchronously, so this winds up meaning that you should simply
be suspicious any time a variable is used inside an anonymous method.

One notable exception to this would be using an anonymous method in a
call to Control.Invoke(). But otherwise, asynchronous scenarios are
typical.

By "suspicious", I don't mean you shouldn't do it. I just mean that you
should consider that to be an enormous red flag, requiring very careful
inspection of the code so that you understand exactly what it's doing.

IMHO, if you take the time to really stop and think about what
"capturing" a variable means, then any time you write an anonymous
method this will be very much in the front of your mind. I think
there's a tendency to read and write code in anonymous methods as if the
captured variable exists in the same context as the declaration of the
anonymous method. But it doesn't have to be that way; just remember
that the captured variable's value is used at the same time as the rest
of the code in the anonymous method is _executed_, and you should be
able to avoid these problems.

Pete

I'm not sure that Sleep nor a loop would help here - really I suspect
all you need is:

for (int i = 0; i < 2; i++)
{
int j = i;
Thread t = new Thread(delegate()
{
Debug.Assert(j != 2);
});
t.Start();
threads.Add(t);
}

By 1.1 standards it looks the same, but j should (IIRC) now be scoped
(and hence captured) *inside* the loop. On each successive loop, the j
is completely different. Without the capture, of course, there is only
a single j declared on the stack at the top of the method... gotta
love capture ;-p

Marc

ahh, frick; sorry Jon - I didn't see your (scarily similar) post.
Deferred posting... oops and apols...

Marc Gravell wrote:
Help with what? The post to which I replied asked if there was a way to
_ensure_ that the two different versions of the code behaved
differently. I don't know why he's unable to reproduce a difference
without changing the samples; assuming he's running on Windows, it's
hard to imagine a scenario where the thread creating the other threads
gets preempted before the i loop exits.

But taking as granted his statement is true and he does in fact have
trouble seeing the difference, there are ways to hack up the code so
that the timing is more deterministic.

Please don't think that the post to which you replied was intended to
address the original issue. My comments there are _strictly_ with
respect to manipulating the code so that it fails in a more obvious,
reproducible way.

Pete

As a follow-on question... where does variable i 'live'. It's local and
a value type, so lives on the local stack...

So... remove the thread.Join() and make the threads take a little longer
e.g.

new Thread( delegate() { Thread.Sleep(5000); Debug.Assert(i!=2); }

The original method will have completed before the thread runs its code.
So where is the 'i' that it's referencing? Won't the stack have changed
by then?




In article <e6FVjpmFIHA.2268 (AT) TK2MSFTNGP02 (DOT) phx.gbl>, cmullins (AT) yahoo (DOT) com
says...