|
|
Featured White Papers
- Why choose an Open Source BPM?
- 10 FAQs on Business Process Management
- Best Practices for Getting Started with BPM
- Free Your Devs From The Pain Of Java Redeploys
- Increase Velocity 40% by Using JRebel
- What Developers Want: The End of Application Redeploys
- Developer Productivity Report: Java Tools, Tech, Devs, and Data
- Coding with JRebel: Java Forever Changed
- Utilizing Fast Testing to Transform Java Development
- Do You Really Get Classloaders?
- Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
- Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
- Coding with JRebel, Java Forever Changed
- 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data
Sponsored Links
Sponsored Links
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Java 101: Understanding Java threads, Part 3: Thread scheduling and wait/notify
Learn about the mechanisms that help you set and manage thread priority
Page 5 of 7
Native thread scheduling
Most JVMs rely on the underlying operating system (such as Linux or Microsoft Windows XP) to provide a thread scheduler. When an operating system handles thread scheduling, the threads are native threads. As with green thread scheduling, priority proves important to native thread scheduling: higher-priority threads typically preempt lower-priority threads. But native thread schedulers often introduce an additional detail: time-slicing.
Note: Some green thread schedulers also support time-slicing. And many native thread schedulers support priority inheritance. As a result, green thread schedulers and native thread schedulers normally differ only in their thread scheduler's source: JVM or operating system.
Native thread schedulers typically introduce time-slicing to prevent processor starvation of equal-priority threads. The idea is to give each equal-priority thread the same amount of time, known as a quantum. A timer tracks each quantum's remaining time and alerts the thread scheduler when the quantum expires. The thread scheduler then schedules another equal-priority thread to run, unless a higher-priority thread unblocks.
Time-slicing complicates the writing of those platform-independent multithreaded programs that depend on consistent thread
scheduling, because not all thread schedulers implement time-slicing. Without time-slicing, an equal-priority runnable thread
will keep running (assuming it is the currently running thread) until that thread terminates, blocks, or is replaced by a
higher-priority thread. Thus, the thread scheduler fails to give all equal-priority runnable threads the chance to run. Though
complicated, time-slicing does not prevent you from writing platform-independent multithreaded programs. The setPriority(int priority) and yield() methods influence thread scheduling so a program behaves fairly consistently (as far as thread scheduling is concerned) across
platforms.
Note: To prevent lower-priority threads from starving, some thread schedulers, such as Windows schedulers, give temporary priority boosts to threads that have not run in a long time. When the thread runs, that priority boost decays. Thread schedulers still give higher-priority threads preference over lower-priority threads, but at least all threads receive a chance to run.
Schedule with the setPriority(int priority) method
Enough theory! Let's learn how to influence thread scheduling at the source code level. One way is to use Thread's void setPriority(int priority); method. When called, setPriority(int priority) sets the priority of a thread associated with the specified thread object (as in thd.setPriority (7);), to priority. If priority is not within the range of priorities that Thread's MIN_PRIORITY and MAX_PRIORITY constants specify, setPriority(int priority) throws an IllegalArgumentException object.
Note: If you call setPriority(int priority) with a priority value that exceeds the maximum allowed priority for the respective thread's thread group, this method silently
lowers the priority value to match the thread group's maximum priority. (I'll discuss thread groups next month.)
- Feedback
More from JavaWorld
Resources
- Download this article's source code and resource files.
- Read every article in the Understanding Java threads series (Jeff Friesen, JavaWorld.com, 2002):
- For a glossary specific to this article, homework, tips, and more, see the Java 101 study guide that accompanies this article.
- For more information about exceptions and the run() method, read "Handling Uncaught Exceptions" ( Glen McCluskey, Java Developer Connection, January 2001).
- The Programming Java Threads in the Real World series uses common programming scenarios to introduce readers to programming Java threads (Alan Holub, JavaWorld.com, 1998-2001):
- Part 1: A Java programmer's guide to threading architectures
- Part 2: The perils of race conditions, deadlock, and other threading problems
- Part 3: Roll-your-own mutexes and centralized lock management
- Part 4: Condition variables and counting semaphores—filling in a few chinks in Java's threading model)
- Part 5: Has Sun abandoned run anywhere? PlusThreads and Swing, timers, and getting around stop(), suspend(), and resume() deprecation)
- Part 6: The Observer pattern and mysteries of the AWTEventMulticaster
- Part 7: Singletons, critical sections, and reader/writer locks
- Part 8: Threads in an object-oriented world, thread pools, implementing socket accept loops