Suspended:
A call to the suspension function [thread.suspend()] has been made. It will remain in this
state until another thread calls the resume function on it.
Zombie:
It is a dead thread and is waiting for its resources to be collected. (This is not a recognizable state
to the user, although it might appear in the debugger. This state does not appear in Java threads at
all, although it may appear in the underlying native library. It is sometimes useful to use this
concept for explaining behavior.)
Figure 5-2 shows a process with eight PCS threads and three LWPs. Five of the threads want to
run, but only three can do so. They will continue to run as long as they want or until one of them
makes a threads library call that changes conditions, as noted above. The two runnable threads are
of equal or lower priority than the three active ones, of course. Should one of the sleeping or
stopped threads be made runnable, whether they actually become active will be a question of
priority levels. If the newly runnable thread is of higher priority than one of the active threads, it
will displace the lowest-priority active thread. If it is of lower priority than all of them, it won't. If
it is of equal priority, we make no guarantees. You should not write a program assuming anything
about this condition. (It would actually be very difficult to write one that did depend on this.)
Figure 5-2. Some Process Contention Scope Threads in Various States
The LWPs that are to be used by the unbound threads are set up in a pool and are identical in all
respects. This setup allows any thread to execute on any of the LWPs in this pool. You should not
change any attributes of these LWPs (e.g., scheduling class, "nice" level), as you don't know
which thread will be running on them at any given time. Should you want a special LWP, you'd
want a bound thread to run on it (not an option in Java).
When an unbound thread exits or goes to sleep (Figure 5-3), and there are no more runnable
threads, the LWP that was running the thread goes to sleep in the kernel. When another thread
becomes runnable, the idling LWP wakes up and runs it. Should an LWP remain idle for an
extended length of time (5 minutes for Solaris 2.5), the threads library may kill it. You will never
notice this. Should your application become more active later, more LWPs will be created for you.
Figure 5-3. Simplified View of Thread State Transitions
Search WWH :
