Windows Threads Behaviour

Thorbar

How's it going everyone. I've been mucking about recently with windows threads and I've run into some odd behaviour. I'm using vc6 and the /MTd flag to compile with on a win 2000 advanced server. Basically I've got 3 threads each printing to stdout, they print a string stateing which thread they are, an local counter a global counter protected with InterlockedExchangeAdd and a global counter they all access with no protection. Here's some of the output:

Hello multithreaded c++ win32 world!
Primary thread is in the cpu! 1 1 1
Primary thread is in the cpu! 2 2 2
Primary thread is in the cpu! 3 3 3
Primary thread is in the cpu! 4 4 4
Apple thread is in the cpu! 1 5 5
Orange thread is in the cpu! 1 6 6
Apple thread is in the cpu! 2 7 7
...
Primary thread is in the cpu! 342 1024 1024
Apple thread is in the cpu! 342 1025 1025
Primary thread is in the cpu! 343 1026 1026
Apple thread is in the cpu! 343 1027 1027
...
Primary thread is in the cpu! 586788 1760330 1760330
Apple thread is in the cpu! 586746 1760331 1760331
Orange thread is in the cpu! 586798 1760332 1760332

it pretty much carries on like this for as far as I've let it run. The point I'm getting to eventually is that InterlockedExchangeAdd is suppose to be there to allow atomic access to a variable for addition. There doesn't seem to be any difference in the behaviour of just directly added to a variable and the supposingly protected functions. Am I not using enough threads to see any conflicts? I'll try spawning a few more and see if that has any affect. Anyway just wondering if anyone else had experience with this.

Thorbar

Ok I've 61 threads accessing the one global variable and its still incrementing correctly. Has this function been decremented and msdn doesn't know about it or is there something else I'm missing here?

GreeBo

total shot in the dark, but could it be something to do with thread priority?
If they all have the same priority will they just run sequentially?