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.
In all likelihood you shouldn't call setPriority at all - it's unlikely to work as you expect it to work, and what's more, that's an area where different JVMs will behave differently, making the code somewhat brittle. (Although, if Henry says otherwise, I would refer to him - he has written the book on this, after all :-)
Tim Moores wrote:In all likelihood you shouldn't call setPriority at all - it's unlikely to work as you expect it to work, and what's more, that's an area where different JVMs will behave differently, making the code somewhat brittle. (Although, if Henry says otherwise, I would refer to him - he has written the book on this, after all
Well, calling setPriority() does set the thread priority. It maps to the underlying threading system's concept of priority. However, two issues...
Some OSes, don't have enough priority levels. When this happens some adjacent java thread priority will map the the same priority level underneath. So, with those OSes, if you try to micro manage it (use all Java thread priority values), you could be doing nothing with certain values.
You are still subjected to the underlying OS scheduler. And with certain OSes, the priority is only a single input into whether a thread should run -- depends on other criteria besides the basic priority level. Some OSes support some sort of mechanism to prevent thread starvation (of low priority threads). And most OSes support priority inheritance, which can also affect the actual priority.
naveen yadav wrote:will you kindly briefly describe what is priority inheritance ?
Priority inheritace is when a thread gets a temporary bump in priority, due to what threads are waiting on locks that it owns. With priority inheritence, if a low priority thread owns a lock, that a high priority thread later wants -- it will be bumped to the higher priority. The reason is... the higher priority thread is blocked waiting for this lock, so the low priority thread needs to run at a higher priority in order to finish up and free the lock for the high priority thread. The low priority thread is "inheriting" the high priority of the high priority thread.