CMPSCI 377: Operating Systems

• User-level threads are threads that the OS is not aware of. They exist entirely within a process, and are scheduled to run within that process's timeslices.
  
  
• The OS is aware of kernel-level threads. Kernel threads are scheduled by the OS's scheduling algorithm, and require a "lightweight" context switch to switch between (that is, registers, PC, and SP must be changed, but the memory context remains the same among kernel threads in the same process).
  
  
  
• User-level threads are much faster to switch between, as there is no context switch; further, a problem-domain-dependent algorithm can be used to schedule among them. CPU-bound tasks with interdependent computations, or a task that will switch among threads often, might best be handled by user-level threads.
  
  
• Kernel-level threads are scheduled by the OS, and each thread can be granted its own timeslices by the scheduling algorithm. The kernel scheduler can thus make intelligent decisions among threads, and avoid scheduling processes which consist of entirely idle threads (or I/O bound threads). A task that has multiple threads that are I/O bound, or that has many threads (and thus will benefit from the additional timeslices that kernel threads will receive) might best be handled by kernel threads.

class TurnstileController
{
    public:
        void Enter();
        void Exit();
        int PrintCurrentOccupants();
        
    private:
        // The number of occupants in the room
        int       occupants;
        
        // A counting semaphore used to track the remaining
        // capacity of the room
        Semaphore capacityRemaining;
        
        // A mutex that only allows one person to enter the room
        // at a time
        Semaphore entranceMutex;
        
        // A mutex that only allows one person to exit the room
        // at a time
        Semaphore exitMutex;
} 

TurnstileController::TurnstileController()
{
    occupants = 0;
    capacityRemaing->value = MAX_CAPACITY;
    entranceMutex->value = 1;
    exitMutex->value = 1;
}

TurnstileController::Enter()
{
    entranceMutex->Wait();
    capacityRemaining->Wait();
    occupants = occupants + 1;
    entranceMutex->Signal();
    
}

TurnstileController::Exit()
{
    exitMutex->Wait();
    occupants = occupants - 1;
    capacityRemaining->Signal();
    exitMutex->Signal();
}

• Both choices have their advantages and drawbacks.

  Test&set works on both uniprocessors and multiprocessors. However, even if implemented carefully, test&set will result in some busy waiting.

  Disabling interrupts will only work on uniprocessors. Worse, the timing of the re-enabling of interrupts is tricky (e.g. in NACHOS, it is the responsibility of the next running thread to re-enable interrupts upon executing).

  Because a modern OS is generally required to run on a multiprocessor architecture, the only real choice is test&set. Hopefully the overhead of some busy-waiting will be an acceptable tradeoff for the increased throughput of multiple CPUs.