From: Muench, Joanna (jmuench_at_fhcrc.org)
Date: Mon Jan 26 2004 - 15:18:11 PST
Anderson, et al (1992) present an interesting approach to controlling
parallelism with a combination of user-level and kernel threads. The paper
motivates the approach by illustrating the problems with supporting threads
either at the user level or within the kernel. User-level threads are
extremely flexible but can have performance problems under multiple
processors. Meanwhile kernel threads must have extensive protections built
into them, and thus are heavy weight. The proposed solution attempts to find
the best of both worlds in creating a threading system using both user-level
and kernel threads.
The solution implements a clever use of user-level threads connected to the
kernel via scheduler activation. This allows user-level threads to progress
pretty much as they would under a uniprocessor. If the kernel needs to
reallocate resources it can terminate a user-level thread through the
scheduler. If processors are available, the kernel upcalls into the user
level regarding availability. The kernel does not directly resume a stopped
thread; instead the user-level thread system takes on this responsibility.
The system uses recovery to deal with the problem of inopportune preemption
by temporarily continuing within a user-level context switch.
The actual implementation of this system on top of the Topaz OS using the
FastThreads package required only a moderate amount of code. The
implementation supported Topaz kernel threads to preserve compatibility with
existing applications. An important feature of the implementation is that
applications can choose their own concurrency policy, although a default
policy is provided. I found the implementation of a recovery solution
extremely interesting and somewhat surprising. But, by identifying critical
sections ahead of time and copying them, a thread within a critical section
can be moved into the copy of the critical section with no impact on lock
latency.
The performance of this system wasn't stellar in comparison to the original
FastThreads, but did show promise when running on six processors (the most
available) with I/O calls. Under this scenario the modified FastThreads can
exploit the available parallelism to overcome some of the I/O latency.
This was a very interesting and informative paper. The first section
provided an excellent overview of the issues of user-level and kernel
thread; I was amused to find some of that discussion echoed in a recent
edition of Stallings's OS text, along with a reproduction of Table I. The
rest of the paper required careful reading to understand some of the more
subtle points of scheduler activation and the recovery system.
This archive was generated by hypermail 2.1.6 : Mon Jan 26 2004 - 15:18:59 PST