G
Guest
Hi all,
In my code I have a bottleneck which consists of a cpu-intensive loop of
size LENGTH. What I did was to divide that loop into two threads, Thread1
doing the 0 to LENGTH/2 part, and Thread2 doing the LENGTH/2 to LENGTH part.
There is no synchronization between threads, so they should work pretty
freely.
My machine has two processors (dual P3, Windows 2003 server). Now comes the
problem: when running the program, both threads are scheduled on the *same*
processor! I checked many things, for example:
1) Added a while(true); infinite loop, and it resulted in each thread be
scheduled to another processor (this was a test of course, I don't need an
infinite loop!).
2) Added the following code the loops in each thread:
for (int i = 0; l < 10000000; i++);
Just an empty loop that wastes CPU. Strangely enough, this somehow signals
to the scheduler that the threads are cpu-intensive and so each thread is
scheduled on different processor.
I would like to mention again that even without this wasteful loop each
thread is already 100% cpu-intensive, and so it is very strange that the
scheduler does not assign each thread to seperate processor.
As a last resort, I tried using a Win API call to SetThreadAffinityMask to
manually assign each thread to seperate processor. This to no avail, as my
request was ignored! (although the SetThreadAffinityMask function did not
return a fail status.) Again, strangely enough, when I use
SetThreadAffinityMask in the while(true) example above to ask the scheduler
to assign both threads to same processor, the scheduler does respect the
request and assigns both threads to same processor.
Finally, I have to mention that within the loops many memory accesses are
done (though no memory allocations). Is it possible that because of this the
scheduler places both threads on same processor to share L1 cache? (Though
after many years of parallel programming in C/C++ I have never encountered
such a strange behavior).
And if not, is it possible that the problem is because of a bug in .NET
Framework thread handling?
Thanks in advance for any reply that might shed some light on this mystery.
In my code I have a bottleneck which consists of a cpu-intensive loop of
size LENGTH. What I did was to divide that loop into two threads, Thread1
doing the 0 to LENGTH/2 part, and Thread2 doing the LENGTH/2 to LENGTH part.
There is no synchronization between threads, so they should work pretty
freely.
My machine has two processors (dual P3, Windows 2003 server). Now comes the
problem: when running the program, both threads are scheduled on the *same*
processor! I checked many things, for example:
1) Added a while(true); infinite loop, and it resulted in each thread be
scheduled to another processor (this was a test of course, I don't need an
infinite loop!).
2) Added the following code the loops in each thread:
for (int i = 0; l < 10000000; i++);
Just an empty loop that wastes CPU. Strangely enough, this somehow signals
to the scheduler that the threads are cpu-intensive and so each thread is
scheduled on different processor.
I would like to mention again that even without this wasteful loop each
thread is already 100% cpu-intensive, and so it is very strange that the
scheduler does not assign each thread to seperate processor.
As a last resort, I tried using a Win API call to SetThreadAffinityMask to
manually assign each thread to seperate processor. This to no avail, as my
request was ignored! (although the SetThreadAffinityMask function did not
return a fail status.) Again, strangely enough, when I use
SetThreadAffinityMask in the while(true) example above to ask the scheduler
to assign both threads to same processor, the scheduler does respect the
request and assigns both threads to same processor.
Finally, I have to mention that within the loops many memory accesses are
done (though no memory allocations). Is it possible that because of this the
scheduler places both threads on same processor to share L1 cache? (Though
after many years of parallel programming in C/C++ I have never encountered
such a strange behavior).
And if not, is it possible that the problem is because of a bug in .NET
Framework thread handling?
Thanks in advance for any reply that might shed some light on this mystery.