Multithreading in C#

I am trying to run the following program from the book.

The author claims 开发者_StackOverflowthat the resultant output " should be "

1000

2000

....

10000

if you run the program on normal processor but on multiprocessor computer it could be

999

1998

...

9998

when using normal increment method (number+=1) but using the intelocked increment as shown in the program solves the problem(i.e. you get first output)

Now I have got 3 questions. First why cant i use normal increment in the inner loop [i++ instead of Interlocked.Increment(ref i)]. Why has author choosed the other method?

Secondly what purpose does Thread.Sleep(1000) has in the context. When I comment out this line, I get second output even if I am using Interlocked method to increment number.

Thirdly I get correct output even by using normal increment method [number += 1] if I dont comment the Thread.Sleep(1000) line and second output if I do so.

Now I am running the program on Intel(R) Core(TM) i7 Q820 cpu if it makes any difference

static void Main(string[] args)
{
    MyNum n = new MyNum();

    for (int a = 0; a < 10; a++)
    {
        for (int i = 1; i <= 1000; Interlocked.Increment(ref i))
        {
            Thread t = new Thread(new ThreadStart(n.AddOne));
            t.Start();
         }            
        Thread.Sleep(1000);
        Console.WriteLine(n.number);
    }
}

class MyNum
{
    public int number = 0;
    public void AddOne() 
    {
        Interlocked.Increment(ref number);
    }
}

The sleep is easy--let the threads finish before you look at the result. It's not really a good answer, though--while they should finish in a second there is no guarantee they actually do.

The need for the interlocked increment in the MyNum class is clear--there are 1000 threads trying for the number, without protection it would be quite possible for one to read the number, then a second read it, then the first one put it back and then the second put it back, wiping out the change the first one made. Note that such errors are FAR more likely when there are multiple cores, otherwise it can only happen if a thread switch hits at the wrong time.

I can't see why i needs to be protected, though.

Edit: You are getting about the same result because the code executes too fast. The thread runs faster than it's created so they aren't running all at once.

Try:

public void AddOne()
{
int x = number + fibnocci(20) + 1 - fibnocci(20);
}

private int fibnocci(int n)
{
if (n < 3) return 1 else return fibnocci(n - 1) + fibnocci(n - 2);
}

(I hope the optimizer isn't good enough to kill this extra code)

The code is actually pretty strange. Since Thread t is declared locally on each iteration, it can possibly be garbage collected by .NET because no reference exists to the thread. Anyway...

To answer the first question, I don't see a need for Interlocked.Increment(ref i) to take place. The main thread is the only thread that will touch i. Using i++ is not a problem here.

For the second question, Thread.Sleep(1000) exists to give the program enough time to complete all the threads. Your i7 (quad core with hyper-threading) is probably finishing each item pretty fast.

For the third question, having the same result is not really a guaranteed with number += 1. The two cores might read the same numeral and increment the numerals to the same value (i.e., 1001, 1001).

Lastly, I'm not sure whether or not you are running the program in debug mode. Building the program in release mode may give you different behaviors and side effects that a multi-threaded program should do.

if you comment out the thread.sleep line, there is a good chance that the threads will not finish prior to the print line... in this case you will see a number smaller than the "correct" output, but not because the incrementer wasn't atomic.

On a true multicore system, it is possible for the non-atomic actions to collide. Perhaps you are doing too few iterations to see the collision.