Chapter 11. Libraries
·
The Native Threads Libraries
·
Multithreaded Kernels
·
Are Libraries Safe?
·
Java's Multithreaded Garbage Collector
In which we explore a variety of operating systems issues that bear heavily upon the usability of
threads in actual programs. We examine the status of library functions and the programming
issues facing them. We look at some design alternatives for library functions.
Multithreading is a fine and wonderful programming paradigm as we have described it thus far.
However, it's not worth too much if it doesn't have the operating system support to make it viable.
Most of the major operating systems are in a state of significant flux, so it would be difficult for us
to say much about all of them. Instead, we will stick with the issues that need to be considered and
describe where the major systems are with respect to them.
The Native Threads Libraries
The native threads library is an integral, bundled part of the operating system for most (Solaris,
IRIX, AIX, Digital UNIX, SCO, HP-UX, Win95, NT, OS/2) but not all OSs (Linux). When it is
bundled, you can write your program and not worry about whether the dynamic library will be
there when you need it. As long as you write your C programs legally, you will be able to move
them across different machines and across different versions of the operating system without any
problems at all.
JVMs that use green threads are independent of the native threads libraries, so there's no issue here
for them. JVMs that do use the native threads library will obviously need that native library in
place.
Multithreaded Kernels
Many of the kernels are implemented using threads (Solaris, NT, OS/2, AIX, IRIX, Digital UNIX,
HP-UX). The kernels generally use the same C API that you have access to (Solaris kernel threads
are very similar, Mach kernel threads are much lower level). There is no inherent connection
between the kernel being multithreaded and the existence of a user-level MT library. Kernel
programmers could have written the user-level library without the kernel being threaded, and they
could have threaded the kernel without supplying a user-level library. They even could have built
LWPs, made them realtime, SMP, and preemptable without the use of threads. Theoretically.
In practice, the same things that make MT so attractive to you also make it attractive to the kernel
hackers. Because the kernel implements all internal schedulable entities as threads, it is much
easier to implement SMP support and realtime scheduling, and make the kernel preemptable. So
LWPs are built on top of kernel threads. Interrupts are built with kernel threads. Creation,
scheduling, synchronization, etc., of kernel threads work much the same way as for user-level
threads.
Search WWH :
