The question of when these things are useful has a somewhat tricky answer, and it changes with
new operating system releases. If schedulers worked perfectly and had ESP, you would never bind
an LWP to a CPU. In practice, it's sometimes otherwise. Java has no interface for binding LWPs to
CPUs.
Happiness Is a Warm Cache
The main issue is that of cache memory latency. The current batch of PCs and workstations have
external caches of significant size (typically, 14 megabytes). To replace the contents of such a
cache completely can take a very long time (upwards of 100 ms, depending upon individual
architecture). If an LWP is running on CPU 0 and it is context switched off for a short time, the
vast majority of that cache will still be valid. So, it would be much better for that LWP to go back
onto CPU 0.
The normal schedulers in the various OSs endeavor to do precisely that via processor affinity
(Figure 5-7). Solaris, for example, will delay running an LWP on CPU 1, should that LWP
previously have been on CPU 0. If CPU 0 becomes available relatively quickly (currently, 30
ms--three clock ticks), that LWP will be put back on CPU 0. If CPU 0 does not become available
within that time frame, the LWP will be scheduled on whatever CPU is available.
Figure 5-7. Processor Affinity
We know of some instances where it has proven valuable to do processor binding of LWPs. If you
are considering this, test first. You should not even consider processor binding unless you already
know that there's a clear problem of this nature. And you must be aware that everything may be
different on a different architecture or different OS release. The details of these issues are well
beyond the scope of this topic, and we wish to caution you that it is rare for anyone to have to
address these issues.
Java Scheduling Summary
Java was designed for writing portable application code across many different types of systems--
various types of UNIX (Solaris, SCO, AIX, Ultrix), Win32, Macintosh, OS/400, MVS, realtime
systems, etc. Consequently, when it came to defining the threading and scheduling model to be
used in Java, it needed to be one that could be supported relatively easily on all platforms. If we
look at what all the primary Java platforms have in common with regard to thread scheduling, we
find almost nothing! Other than having threads and thus needing to schedule them, all the systems
are very different. This resulted in Java defining a very loose scheduling model:
·
All Java threads have a priority and the scheduler will generally give preference to
executing the highest-priority runnable thread (i.e., it is notionally priority preemptive).
However, there is no guarantee that the highest-priority thread is always running.
·
A system may apply time slicing to threads, but it is not required to. If time slicing does
exist, whether it applies across all threads or only within priority levels, is not defined.
Search WWH :
