Threads, SMP and Microkernels

1
Threads, SMP and Microkernels

• B.Ramamurthy
• Chapter 4

2
Thread

• Unit of work
• A process has address space, registers, PC and
  stack (See man fork for the detailed list)
• A thread has registers, program counter and
  stack, but the address space is shared with
  process that started it.
• This means that a user level thread could be
  invoked without assistance from the OS. This low
  overhead is one of the main advantages of
  threads.
• If a thread of a process is blocked, the process
  could go on.
• Concurrency Many threads could be operating
  concurrently, on a multi threaded kernel.
• User level scheduling is simplified and realistic
  (bound, unbound, set concurrency, priorities
  etc.)
• Communication among the threads is easy and can
  be carried out without OS intervention.

3
Thread requirements

• An execution state
• Independent PC working within the same process.
• An execution stack.
• Per-thread static storage for local variables.
• Access to memory and resources of the
  creator-process shared with all other threads in
  the task.
• Key benefits less time to create than creating a
  new process, less time to switch, less time to
  terminate, more intuitive for implementing
  concurrency if the application is a collection of
  execution units.

4
Examples of thread usage

• Foreground and background work Consider
  spreadsheet program one thread could display
  menu and get response while another could be
  processing the request. Increases the perceived
  speed of the application.
• Asynchronous processing Periodic backup
  (auto-saving) of RAM into disk. A thread could
  schedule itself to come-alive every 1 minute or
  so to do this saving concurrently with main
  processing.
• Speed execution In hard-core data-processing
  simple concurrency can speed up process.
• Transaction processing Many independent
  transactions can be modeled very nicely using
  threads. Such applications as neural networks,
  searches, graphics, agent/actor model suit well
  for thread-implementation.

5
Multithreading

• Multithreading refers to the ability of the
  operating system to support multiple threads of
  execution within a single process.
• A process is defined as the unit of protection
  and the unit of resource allocation. It has a
  virtual address space, protected access to
  processors, IPC, files, IO resources.

6
Threads within Processes

• A process may have one or more threads with
• 1. A thread execution state
• 2. A thread context when not running (independent
  PC)
• 3. An execution stack
• 4. Static storage for local variables
• 5. Shared access to the memory and resources of
  the process in which it resides.

7
Thread Operations

• Basic Operations associated with a thread are
• Spawn newly created into the ready state
• Block waiting for an event
• Unblock moved into ready from blocked
• Finish exit after normal or abnormal
  termination.

8
Issues

• When a thread blocks should the process
  associated with it blocked?
• Do we need different types of threads for process
  context and kernel context?
• Should a thread be bound to a processor? If so,
  when?
• How about daemon threads ? Just like zombie
  processes?
• Thread scheduling user level control?
• How many concurrent threads?
• How about thread synchronization?

9
User-level Threads

• User Level Threads (ULTs) concept is supported by
  a thread library.
• All the thread-related operations are supported
  by the library creating, destroying, passing
  messages, scheduling, saving and restoring
  contexts.
• An OS may support only ULT
• Example Encore multimax system (sybil) NO
  Kernel level threads

10
ULT Advantages and Disadvantages

• Advantages
• No kernel interventions.. Overhead low
• Application level scheduling
• No changes needed in kernel to run ULT.
• Disadvantages
• If a kernel process blocks, then entire process
  in which the thread is blocked.
• Multithreading cannot make use of kernel level
  multiprocessing.

11
Kernel-level Threads (KLT)

• Lets consider a kernel that supports threads. Any
  thread in a process will be mapped on to a kernel
  level thread.
• Pure kernel level approach is used by OS/2 and
  Windows NT.
• It works quite nicely except for the fact that
  switching between two threads within a process
  requires kernel more switch!

12
Combined Approach ULT KLT

• Approach used in Solaris.
• Thread creation, synchronization and scheduling
  done at user level.
• Several ULTs mapped to few KLTs.
• User may adjust number of KLTs (get and set
  concurrency).
• Reading (not in the book) Posix thread standard.

13
Solaris OS

• Supports process, user level thread, LWP and
  kernel level thread
• Symmetric Multi Processing
• Process System call goes thru the same sequence
  as any other system

14
System Call

• 1. Process traps to kernel.
• 2. Trap handler runs in kernel mode and saves all
  regs.
• 3. Handler sets stack pointer to processs kernel
  stack.
• 4. Kernel runs system call.
• 5. Kernel places any requested data into user
  spaces structure.
• 6. Kernel changes any process structure values
  affected.
• 7. Process returns to user mode, replaces reg and
  stack and returning value from system call.

15
Solaris Support for Multithreading
Process
user
LWP
Kernel threads
kernel
bound
processors
hardware
16
Thread Support in Solaris

• Programmers write applications using thread
  library.
• User threads are scheduled into LWPs.
• LWPs are in turn implemented using kernel
  threads.
• More than one user thread may map onto an LWP.
• Kernel threads in turn are scheduled on available
  CPU.
• LWP syscalls are handled exactly as specified
  above.

17
Unix and Solaris Process Structure
LWP2
LWP1



18
Process State and LWP state

• Process state and LWP state in the above figure
  contain
• LWP id (if applicable)
• Priority
• Signal mask
• registers
• Stack
• other process state details.

19
Blocking

• Many LWPs can be scheduled independently.
• There is a kernel stack for each LWP.
• Each thread can issue a system call, but blocking
  of this thread will not block the process.
• For example, 10 threads of a process can be
  blocked on read, but 10 other sin the process can
  be computing.

20
Emergence of thread standard

• 1991 .. No major commercial OS had contained
  robust user-level threads library.
• 1997.. Every major player in the computer
  industry has one (thread library).
• OS themselves are multithreaded!
• Posix standard emerged as expected followed very
  closely Solaris (leading player) multithreading
• Pthreads emerged.

21
Thread control - posix style

• creation pthread_create (tid, attr, start_fn,
  arg)
• exit pthread_exit(status)
• join pthread_join(thr_name, status)
• cancel pthread_cancel(thr_name)
• We will look into synchronization mechanisms when
  studying process synchronization.

22
Symmetric Multiprocessing (SMP)

• Greatest push towards multithreading came with
  the emergence of SMP.
• Multithreading provides exactly the right
  paradigm to make maximal use of these new concept
  (SMP).
• When we have multiple threads at user level,
  multiprocessor at the hardware level can exploit
  the user-level concurrency.

23
SMP (contd.)

• Multiple processors.
• Tightly coupled shared memory.
• Kernel can execute on any processor.
• Each processor self-schedules from a pool of
  processes and threads.
• Parts of kernel can execute concurrently on
  different processors!
• OS design is complex, but performance improvement
  is great.

24
Key Design Issues

• Simultaneous concurrent processes or threads
  kernel routines should be reentrant.
• Interconnection structures
• Memory management multi-port memory, cache
  coherence
• Syncronization Mutual exclusion.

25
Microkernels

• A microkernel is a small operating system core
  that provides the foundation for modular
  extensions.
• Typically a microkernel is surrounded by a number
  of subsystems to support extended functionality
  of an operating system.
• See Fig.2.16, 2.13 for examples of leyered and
  micro-kernel systems.

26
Layered vs Microkernel
mode
user
users
Memory mgt.
User mode
File server
Process server
File System
Device driver
Client process
IO and Device subsys.
kernel
Virtual memory
Kernel mode
Primitive process mgt.
Microkernel
Hardware
Hardware
27
Microkernel Philosophy

• Absolutely essential core operating system
  functions should be in kernel.
• Less essential services and applications are
  built on the microkernel and execute in user
  mode.
• OS components outside the microkernel are
  implemented as server processes.
• These components interact by message passing thru
  the kernel.

28
Benefits of Microkernel

• Uniform Interface processes need not distinguish
  between kernel-level and user-level services
  because all services are provided by means of
  message passing.
• Extensibility Adding a new service to the OS
  does not involved rewriting the kernel. Just add
  a (vertical pillar) server on the microkernel.

29
Benefits of Microkernel(contd.)

• Flexibility Not only adding features easy but
  also removing features to provide an efficient,
  optimized OS.
• Portability Only the microkernel is processor
  dependent. Changes to port to newer processor are
  fewer.
• Reliability Small microkernel can be rigorously
  tested.

30
Microkernel

• Distributed system support Lends itself to
  distributed system control. Components (server)
  need not be in a single central location. They
  can be distributed.
• Object-oriented system Decomposition of the
  traditional kernel into microkernel and servers
  yields very nicely to OO design.

31
Windows NT

• Fig.2.13 structure of Windows NT
• Windows NT is a multitasking, multi-threaded
  (single-user) and SMP. Four layers
• Hardware application layer (HAL) Abstracts the
  underlying hardware by mapping between generic
  hardware commands to those unique to a specific
  platform Intels Pentium, PowerPC, DECs alpha.
  Provides the support for symmetric
  multiprocessing.
• Microkernel Scheduling, context-switching,
  exception and interrupt handling, and
  multi-processor synchronization.

32
Windows NT (contd.)

• NT executive Object-manager, security monitor,
  process manager, virtual memory management
• IO manager file system, cache manager, device
  manager, network drivers.
• System services Interface to user-mode services.
• Protected-subsytem servers Outside the kernel.
  Ability to support applications written for other
  operating systems.
• Executive, protected sub-systems, and
  applications are structured using client/server
  computation model.

33
Protected subsytem

• Provides commands and GUI that emulates various
  OS OS2, POSIX, Win32.
• Provides API (Application Programming Interface)
  for the operating system emulated. This means
  that the applications created for a particular
  operating system may run unchanged on NT. In many
  cases recompile is all that is required.
• Client/server model used simplifies base OS,
  reliability, base for distributed computing.

34
Client/server model (windows NT)

• Each server is implemented as one or more
  processes memory services, process creation
  services, scheduling services etc.
• A client which may be an application program or
  OS process requests a service by sending a
  message.
• Executive directs the message to appropriate
  server.
• Server completes the request and returns the
  message through the Executive back to the client.

35
Multi-threaded and SMP

• Windows NT supports threads within processes.
• SMP Symmetric Multi - Processing allows for any
  process or thread can be assigned to any
  processor by the kernel.
• Design for exploiting SMP
• OS routines can run on available processors.
• Multiple threads of the same process can execute
  on different processors.
• Server process may use multiple-threads to take
  request from multiple users at the same time.
• Provides ease of sharing data and resources, and
  flexible IPC.

36
Processes and threads

• NT has two types of process-related objects
  processes and threads.
• A process corresponds to a user job or
  application that owns resources, such as memory,
  and files. A thread is dispatchable unit of work
  that executes sequentially and is interruptible.
• NT kernel does not maintain any relationship
  among the processes that it creates, including
  parent-child relationship.
• NT process must contain at least one thread to
  execute. This thread may then create other
  threads.

37
process class

• An object is an instantiation of a class.
• A simple class definition contains attributes
  (data structures) and methods (operations,
  services /functions). These attributes could be
  private, public (and/or protected).
• Description of NT process in Fig.4.11.
• See an excellent description of classes for
  process and thread in Fig.4.12.

38
Support for NT Subsystems

• It is the responsibility of the OS subsystem to
  exploit the NT process and thread features to
  emulate facilities of its OS. (Obviously each OS
  has its own subsystem.)
• Application requests process creation gt
  protected subsystem gt process request to NT
  executive gt NT ex. instantiates an object
  process and returns handle of the object to the
  subsystem.

39
Support for NT Subsystems (contd.)

• But win32 and OS/2 processes are always created
  with a thread... so the subsystem issues one more
  request to the NT executive to instantiate and
  return a handle for a thread. After this the
  process and thread handle are returned to the
  application program.
• NT allows subsytem to specify the parent of the
  new process for inheriting its attributes.
• NT has no predetermined relationship among procs.
  Both OS/2, win32 and unix have parent -child
  relationship. This is solved by using handles

40
Windows NT objects

• Based on object-oriented design paradigm.
  Facilitates sharing of data and resources at the
  same providing protection from unauthorized use.
• Entities represented as objects files,
  processes, threads, semaphores, timers, windows.
• Object manager takes takes care of creation,
  destruction.