This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Thread control is OS specific, the operating system chooses which Thread should get CPU cycles when. By setting the priority you give the OS a hint that Threads with higher priority should get more CPU cycles than Threads with lower priority. It is not something you can easily test with short-running Threads that don't hog CPU cycles. For example, in your code your Threads don't use a lot of CPU time, they go to sleep, which doesn't use the CPU, so there will be no Thread contention and the OS doesn't have to choose which Thread to run. In another point, the priority really only comes into play when Thread context needs to switch, so you will NOT see the affect of Priority when the number of Threads is less than or equal to the number of CPUs.
So to properly test Priority you would need a test suite which has more Threads than your computer has CPUs. And each Thread would need to be processor intensive, like by doing a lot of calculations and no waiting/blocking.
Joined: May 05, 2009
thanks..if i didn't use sleep method.....at first thread with priority 5 is executing first........
Thamarai kannan wrote:thanks..if i didn't use sleep method.....at first thread with priority 5 is executing first........
The Priority doesn't force anything, it is a hint. It doesn't guarantee who starts first, but suggests which should get more CPU time. A better test would be to set an infinite loop in the Threads that do some calculation and tracks the number of cycles performed. Then peek at the results on occasion and see which thread is doing more calculations. Over time, the Thread with the higher priority should get farther than the one with lower priority. The effect is only seen over time, and does not force the OS to choose one Thread over another.