Notes by Jia Wang and Lili Qiu (2/26/98)

Ideas

• dilemma:
  • user-level thread: good performance, flexible, correct behavior provid ed the application is uniprogrammed and does no I/O
  • kernel-level thread: worse performance, but not as restricted
• goal: design a kernel interface and a user-level thread package that can c ombine the functionality of kernel threads with performance and flexibility of user-lev el threads
• approach:
  • provide each application with a virtual multiprocessor
  • run user-level threads on the top of scheduler activations

Design

• the operating system kernel provides each user-level thread system with it s own virtual multiprocessor
• kernel controls the allocation of processors to each address space
• user-level thread system controls which threads to run on its allocated pr ocessors
• kernel vectors the kernel events to the user-level thread scheduler - sche duler activation
• user-level thread system notifies the kernel of user-level events affectin g processor allocation
  • only notifies the kernel of a small subset of thread operations that m ight affect processor allocation decisions.
  • notifies the kernel whenever it makes a transition to a state where it has more runnable threads than processors, or more processors than runnable threads
  • the user-level threads system need serialize its notifications to the kernel
  • multi-level feed back can be used to encourage applications to provide honest information for processor allocation decisions: processor allocator favo r address spaces that use fewer processors
• user-level thread system manages its virtual multiprocessor transparently to the application programmer
• dealing with critical section problem - recovery based approach

Implementation

• implement scheduler activation to perform upcalls
• do explicit allocation of processors to address spaces using space-shares
• thread scheduling
  • uses per-processor ready lists accessed by each processor in last-in-f irst-out order
  • avoid unnecessary processor reallocations by spinning an idle processo r before reallocation
• performance enhancements
  • critical section
    • the thread sets a flag when it enters a critical section, clears t he flag when it leaves, and then checks to see if it is being continued
    • the authors' approach:
    1. make an exact copy of every low-level critical section
    2. place code to yield the processor back to the resumer at the end of copy
    3. normal execution uses the original code.
    4. when a preemption occurs, the kernel starts a new scheduler acti vation to notify the user-level thread system; this activation checks the preempted thr ead's PC to see if it is in a critical section, if so, continues the thread at the place in the copy of the critical section. The copy relinquishes control back to the origin al upcall at the end of the critical section.
  • management of scheduler activation
    • recycle old scheduler activations
    • collect and return the discarded scheduler activations in bulk
• debug
  • user-level thread system and application code
  • the kernel assigns each scheduler activation a logical processor to av oid upcalls into user-level thread system during debugging.

Performance

• cost of user-level thread operations
  • comparable to FastThreads on Topaz threads
  • small degradation due to changing the number of busy threads, determin ing whether the kernel must be notified, and checking whether a preempted thread is bein g resumed
• cost of communication between the kernel and the user level
  • considerably worse than expected due to building scheduler activation (1) as a modification to the Topaz kernel thread system, and (2) using Modula-2+
• the overall effect on the performance of the applications
  • runs as quickly as original FastThreads when making minimal use of ker nel
  • runs faster than the others when requiring considerable kernel involve ment

Discussion

• Do you think any advantage or disadvantage of the scheduler activation sch eme?
• Is there any system that adopt scheduler activation scheme to manage threa ds?
• What is the good thread paradigm to support concurrent programs?