Given such a loose specification for scheduling, how can we write portable code? The answer is to
never make optimistic assumptions about scheduling behavior but always assume the worst:
·
You must assume that threads could be interleaved at any point in time.
·
You must not require that threads be interleaved at some time. If you need to guarantee
that different threads make progress, you will have to explicitly code things such that
progress can occur.
How Many Threads in Java?
The Java spec does not state how many threads an implementation must support. The actual
number is completely implementation dependent. Presumably, the number will be the same as the
limit on the underlying native library. For JVMs based on POSIX threads (most UNIX
implementations, Linux, VMS, AS/400), this will be a minimum of 64. The actual maximum is
undefined, but probably at least 1000. On Solaris, for example, the limitation is strictly the amount
of virtual memory you have, hence about 4000 threads on 32-bit Solaris, assuming minimal
program and data size and the default 500k stack. On Windows NT the number of threads is more
limited, as small as 64. (See NT documentation for details.) One implementation, BulletTrain
from Natural Bridge Inc., actually builds a two-level model on top of NT, allowing Java to have
more than 8000 threads simultaneously.
If you want more than a few hundred threads, be careful! You are probably doing something
wrong.
When Should You Care About Scheduling?
There are times when you will want to deal with scheduling directly, but those times are few and
far between for any of the libraries. If you find yourself thinking about this a lot, you're probably
doing something wrong. Some examples follow.
It is possible to design a server program where each thread runs forever, picking up requests off
the net, processing them, and returning for more. It is possible for an unbound thread to get starve
for CPU time in this situation. In this case you should add LWPs for the purpose of effecting a
time-slicing scheme.
A program that used a set of threads to produce data and another single thread to push that data
out to some device in realtime needs to ensure that the output thread runs when it needs to. Here a
where they built a high-speed printer driver, they found it worthwhile to make a bound thread and
put the LWP into the realtime class.
In spite of all the attention we just paid to explaining it, you will not write much (if any!) code to
deal with it. If the library writers did their job well, everything will "just work," without any effort
on your part. In most MT programs, the different threads all depend upon one another, and it
doesn't really matter which one runs first. Sooner or later, the running threads will need something
from the other threads, and they will be forced to sleep until those other threads have produced
that something.
APIs Used in This Chapter
Search WWH :
