March 16, 2001, 5:02 PM —
Solaris 8 adds several new features to its already powerful set of thread APIs. Key features include:
- Alternate one-level libthread library
- Priority inheritance for user threads
- Priority ceilings for mutex locks
- Robust mutex locks
Let's have a look.
Alternate one-level threads library
Solaris implements a two-level threads architecture (see August 1998's column as well as subsequent columns covering the process model).
The two-level model is implemented by abstracting the user thread as something separate and distinct from the kernel thread and lightweight process (LWP). Hopefully, our previous discussion on bound and unbound threads clarified the distinction between the two types of threads. Experience has shown that a number of threaded applications can benefit from using bound over unbound threads. However, changing the source or recompiling the application may not be possible or practical. For such situations, the alternate libthread library was shipped with Solaris 8.
By linking a multithreaded application to the alternate library, all threads are created as bound threads. That is, every thread is created with an LWP and linked to the LWP for the thread's lifetime. The alternate thread's library is maintained in the /usr/lib/lwp directory (32-bit) and /usr/lib/lwp/64 for 64-bit programs. You can link to the alternate libthread either through a compilation flag or by setting the runtime linker's LD_LIBRARY_PATH variable.
Here's a simple compile of a thread's program using POSIX threads, followed by a run of the ldd(1) command on the resulting binary (ldd(1) lists the dependencies of dynamically-linked objects).
sunsys> cc -o ptdemo ptdemo.c -lpthread
sunsys> ldd ptdemo
libpthread.so.1 => /usr/lib/libpthread.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
As you can see from the ldd(1) output, libpthread.so.1 and libthread.so.1 are resolved from the /usr/lib directory. Note that the sample program, ptdemo, uses POSIX threads and doesn't have a direct dependency on libthread.so.1. The dependency on libthread.so.1 is in libpthread.so.1, the POSIX threads library. That is an important point in understanding the procedure for linking to the alternate thread's library for programs that use POSIX threads.
Now we recompile, using the -R flag, which specifies a path for the runtime linker to search.
sunsys> cc -o ptdemo ptdemo.c -lpthread -lthread -R/usr/lib/lwp
sunsys> ldd ptdemo
libpthread.so.1 => /usr/lib/libpthread.so.1
libthread.so.1 => /usr/lib/lwp/libthread.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
sunsys>
Looking at the ldd(1) output, we see that libthread.so.1 is now resolved from /usr/lib/lwp, which is the alternate thread's library. Note the addition of -lthread preceding the -R flag in the compile line. That is necessary for POSIX thread programs because of the dependency we mentioned earlier. An alternate libpthread.so.1 is not necessary, as the internal thread create function used by both POSIX and Solaris threads is part of the libthread.so.1. The POSIX library, libpthread.so.1, exists to set up POSIX-related features and attributes and support POSIX semantics.
If you're using Solaris threads, simply specify the runtime linker path following the libthread inclusion. You would use:
sunsys> cc -o soltdemo soltdemo.c -lthread -R/usr/lib/lwp
