1. Introduction
	1.1. Project/Component Working Name:
		Scheduler Activations

	1.2. Name of Document Author/Supplier:
		Andrew T.

	1.3. Date of This Document:
		01/17/96

	1.4. Name of Major Document Customer(s)/Consumer(s):
		PSARC
		OSSC

2. Description
	Scheduler activations (aka thread control) provides a
	communication channel between the kernel and the
	multithreading library.  Currently, the threads library has
	insufficient information to make proper scheduling decisions.
	Scheduler activations provides this information and other
	scheduling support in a way that causes little performance
	overhead for multithreaded applications.

	The result is the solution of a number of problems inherent in
	the current implementation of the threads library.  These
	include priority inversion, synchronization performance, and
	the performance of concurrently running compute-intensive
	applications.  The changes are implemented as a private
	interface between the threads library and the kernel without
	affecting the threads API.

3. External Requester
	Many customers have asked for a solution to the problem of
	thread priority inversion.  The current workarounds (bound
	threads, real-time scheduling) are not satisfactory.

	Customers have also requested gang scheduling to improve
	the performance of concurrently running compute-intensive
	applications.  Scheduler activations solves the same problems
	without impact on single-threaded applications (as occurs with
	gang scheduling).

4. Opportunity Window/Exposure
	This technology has been developed in the academic research
	community over the past 6-7 years.  Currently there are no
	commercial offerings, although SGI is known to be working on
	one for a future release of IRIX.  Sun potentially has the
	chance to be the first on the market with this.

5. Business Opportunity/Exposure
	Multithreading is an important part of the Solaris marketing
	story.  An increasing number of Solaris applications are using
	MT to take advantage of the parallelism in their applications
	and on the ever-growing number of MP systems. It is vital that
	we continue to improve our MT support to stay competitive.
	Scheduler activations provides both better performance for MT
	applications and a fuller implementation of the supported
	interfaces (thread priorities).

6. Technical Description
	The current implementation of Solaris threads has a number of
	problems due to the two-level design.  The threads library
	schedules threads onto lightweight processes (lwps), but has
	no control over how lwps are scheduled onto processors.
	Thread priorities are of limited use when an lwp running a
	high priority thread may be preempted by one running a low
	priority thread (priority inversion).  Efficient
	synchronization is not possible as there is no way to tell if
	the thread holding a lock is running or preempted.  MT
	applications that run well given exclusive access to an MP
	machine often perform poorly when contending for processors in
	a multiprogrammed environment.

	Scheduler activations attempts to solve these problems by
	promoting closer cooperation between the kernel and the
	threads library.  The kernel performs actions in response to
	state transitions in the lwps of a multithreaded application
	to support an improved response from the threads library.
	These actions include making lwp state information available
	to the threads library, generating "upcalls" from kernel to
	user in response to events requiring immediate attention, and
	supporting "handoffs" of a CPU from one lwp to another.

7. Reference Documents
	Bug 1167002, "thread priorities do not work reliably".
	RFE 1127715, "gang scheduling requested".

	"A Scalable Multi-Discipline, Multi-Processor Scheduling
	Framework for IRIX" by James Barton and Nawaf Bitar of SGI
	mentions SGI's future scheduler plans.

	A draft of the detailed scheduler activations design is in
	/home/t/sact/design.ps.  This includes a reference
	list of other work in the area.

8. Projected Availability
	Ready to integrate 4/96.

9. Cost of Effort
	1 staff-year.
	
10. Prototype Availability
	Prototype available now.

11. Prototype Cost
	6 staff-months.

12. Cost of Capital Resources
	No additional capital equipment needed.