Download Figure 5.01

Chapter 4: Threads
Chapter 4: Threads
 Overview
 Multithreading Models
 Threading Issues
 Pthreads
 Windows XP Threads
 Linux Threads
 Java Threads
Operating System Concepts
4.2
Silberschatz, Galvin and Gagne ©2005
Threaded Applications
 Web browsers: display and data retrieval
 Web servers
 Many others
Operating System Concepts
4.3
Silberschatz, Galvin and Gagne ©2005
Threads
 What is a thread ?

Lightweight Process (LWP)?

Basic unit of CPU utilization

Contains

Thread ID

Program counter

Register set

Stack
 Why multithreading ?

Creating processes are expensive

Other advantages
Operating System Concepts
4.4
Silberschatz, Galvin and Gagne ©2005
Single and Multithreaded Processes
Operating System Concepts
4.5
Silberschatz, Galvin and Gagne ©2005
Benefits
 Responsiveness
 Resource Sharing

share memory and resources of the process they belong to

Sharing code and data allow different threads of activity within
the same address space
 Economy

Processes are expensive to create, and do context-switch

In Solaris

Process creating is about 30 times slower

Context-switch is about 5 times slower
 Utilization of MP Architectures

A single-threaded process can only run on one CPU
Operating System Concepts
4.6
Silberschatz, Galvin and Gagne ©2005
User Threads
 Thread management (creation, scheduling) done by user-level
threads library
 Drawback

Blocking system call suspends other threads in the same
process
 Three primary thread libraries:

POSIX Pthreads

Win32 threads

Java threads
Operating System Concepts
4.7
Silberschatz, Galvin and Gagne ©2005
Kernel Threads
 Supported by the Kernel
 Advantages

Non-blocking thread execution

Multi-processors (threads on different processors)
 Drawback

Slower to create and manage than user-level
 Examples

Windows XP/2000

Solaris

Linux

Tru64 UNIX

Mac OS X
Operating System Concepts
4.8
Silberschatz, Galvin and Gagne ©2005
Multithreading Models
 Many-to-One
 One-to-One
 Many-to-Many
Operating System Concepts
4.9
Silberschatz, Galvin and Gagne ©2005
Many-to-One
 Many user-level threads mapped to single kernel thread
 Thread management is done by thread lib. in user space; so, it is
efficient. But,

a thread making a blocking system call block the entire
process

Multiple threads cannot run in parallel on MP computers (only
one thread can access the kernel at a time)
 Used on systems that do not support kernel threads.
 Examples:

Solaris Green Threads

GNU Portable Threads
Operating System Concepts
4.10
Silberschatz, Galvin and Gagne ©2005
Many-to-One Model
Operating System Concepts
4.11
Silberschatz, Galvin and Gagne ©2005
One-to-One
 Each user-level thread maps to a kernel thread
 More concurrency than many-to-one: allowing another thread to
run when a thread makes a blocking system call; allowing multiple
threads running on MP computers as well
 Overhead: creating a kernel thread upon a user thread
 Examples

Windows NT/XP/2000

Linux

Solaris 9 and later
Operating System Concepts
4.12
Silberschatz, Galvin and Gagne ©2005
One-to-one Model
Operating System Concepts
4.13
Silberschatz, Galvin and Gagne ©2005
Many-to-Many Model
 Allows many (K) user level threads to be mapped to many (M)
kernel threads: M<=K
 Allows the operating system to create a sufficient number of
kernel threads without overburdening the system
 Solaris prior to version 9
 Windows NT/2000 with the ThreadFiber package
Operating System Concepts
4.14
Silberschatz, Galvin and Gagne ©2005
Many-to-Many Model
Operating System Concepts
4.15
Silberschatz, Galvin and Gagne ©2005
Two-level Model
 Similar to M:M, except that it allows a user thread to be
bound to kernel thread
 Examples

IRIX

HP-UX

Tru64 UNIX

Solaris 8 and earlier
Operating System Concepts
4.16
Silberschatz, Galvin and Gagne ©2005
Two-level Model
Operating System Concepts
4.17
Silberschatz, Galvin and Gagne ©2005
Threading Issues
Due to multithreading:
 Semantics of fork() and exec() system calls
 Thread cancellation
 Signal handling
 Thread pools
 Thread specific data
 Scheduler activations
Operating System Concepts
4.18
Silberschatz, Galvin and Gagne ©2005
Semantics of fork() and exec()
 Does fork() duplicate only the calling thread (single-threaded
process) or all threads?
 It depends on applications
 Example: if call exec() after fork?
Operating System Concepts
4.19
Silberschatz, Galvin and Gagne ©2005
Thread Cancellation
 Terminating a thread before it has finished
 Examples

Multiple threads are concurrently doing the same task

Cancel web browser’s on-going tasks
 Two general approaches:

Asynchronous cancellation terminates the target
thread immediately

Deferred cancellation allows the target thread to
periodically check if it should be cancelled
Operating System Concepts
4.20
Silberschatz, Galvin and Gagne ©2005
Signal Handling

Signals are used in UNIX systems to notify a process that a particular
event has occurred

A signal handler (user-defined handler overrides default handler) is
used to process signals


1.
Signal is generated by particular event
2.
Signal is delivered to a process
3.
Signal is handled
Depends on signal type

Synchronous signals (e.g., division by 0, illegal memory access)
delivered to the thread causing the signal

Asynchronous signals have options
Options:

Deliver the signal to the thread to which the signal applies

Deliver the signal to every thread in the process, e.g, ctrl-c

Deliver the signal to certain threads in the process: kill(aid, signal)

Assign a specific thread to receive all signals for the process
Operating System Concepts
4.21
Silberschatz, Galvin and Gagne ©2005
Thread Pools
 Create a number of threads in a pool where they await work
 Advantages:

Usually slightly faster to service a request with an existing
thread than create a new thread

Allows the number of threads in the application(s) to be
bound to the size of the pool
Operating System Concepts
4.22
Silberschatz, Galvin and Gagne ©2005
Thread Specific Data
 Threads belonging to a process share the data of the
process
 Allows each thread to have its own copy of data
 Useful when you do not have control over the thread
creation process (i.e., when using a thread pool)
Operating System Concepts
4.23
Silberschatz, Galvin and Gagne ©2005
Scheduler Activations
 Both M:M and Two-level models require communication to
maintain the appropriate number of kernel threads allocated
to the application by an immediate data structure called LWP
(light-weight process), a virtual processor
 LWP runs a user thread; LWP maps to a kernel thread which
the OS schedules to run on the physical processor
 Scheduler activations provide upcalls - a communication
mechanism from the kernel to the thread library; upcall
handler perform the task, mapping a user thread to a new
LWP, or removing a user thread being blocked from a LWP
 The kernel provides a LWP for a user thread
 This communication allows an application to maintain the
correct number kernel threads
Operating System Concepts
4.24
Silberschatz, Galvin and Gagne ©2005
Pthreads
 A POSIX standard (IEEE 1003.1c) API for thread
creation and synchronization
 API specifies behavior of the thread library,
implementation is up to development of the library
 Common in UNIX operating systems (Solaris, Linux,
Mac OS X)
Operating System Concepts
4.25
Silberschatz, Galvin and Gagne ©2005
Windows XP Threads
 Implements the one-to-one mapping
 Each thread contains

A thread id

Register set

Separate user and kernel stacks

Private data storage area
 The register set, stacks, and private storage area are known
as the context of the threads
 The primary data structures of a thread include:

ETHREAD (executive thread block)

KTHREAD (kernel thread block)

TEB (thread environment block)
Operating System Concepts
4.26
Silberschatz, Galvin and Gagne ©2005
Linux Threads
 Linux refers to them as tasks rather than threads
 Thread creation is done through clone() system call
 clone() allows a child task to share the address space
of the parent task (process)
Operating System Concepts
4.27
Silberschatz, Galvin and Gagne ©2005
Java Threads
 Java threads are managed by the JVM
 Java threads may be created by:

Extending Thread class

Implementing the Runnable interface
Operating System Concepts
4.28
Silberschatz, Galvin and Gagne ©2005
Java Thread States
Operating System Concepts
4.29
Silberschatz, Galvin and Gagne ©2005
Project1: Unix Shell with History Feature
 Goals
 Descriptions
 Methodology
 Submission
Operating System Concepts
4.30
Silberschatz, Galvin and Gagne ©2005
Goals
 Understand how a simple shell works.
 Understand systems calls, such as fork, read, wait, execvp, and
etc.
 Understand signal handling mechanisms
Operating System Concepts
4.31
Silberschatz, Galvin and Gagne ©2005
Descriptions
 Demo

command> ls

commnad> cat proj1.c

command> ctr-c

command> ctr-d
 Input: commands from keyboard
 Fork a child process to perform the command
 Store the past commands in a buffer
 Given a signal, display the most recent commands in the buffer
 Ctrl-C terminates the shell
Operating System Concepts
4.32
Silberschatz, Galvin and Gagne ©2005
Methodology
 How to get the command from the keyboard?

Use system call read() with STDIN_FILENO

Implement a setup()
void setup(char inputBuffer[], char *args[], int *background)
setup() reads in the next command line, separating it into
distinct tokens using whitespace as delimiters. setup() sets the
args parameter as a null-terminated string. Also set
background =1 if & is met
If “ctrl-d” is met, just simply call exit(0);
Operating System Concepts
4.33
Silberschatz, Galvin and Gagne ©2005
Methodology
 How to execute the command?
 while (1){ /* Program terminates normally inside setup */

background = 0;

printf(" COMMAND->\n");

setup(inputBuffer,args,&background); /* get next command */

/* the steps are:

(1) fork a child process using fork()

(2) the child process will invoke execvp()

(3) if background == 1, the parent will wait,

otherwise returns to the setup() function. */
 }
Operating System Concepts
4.34
Silberschatz, Galvin and Gagne ©2005
Methodology


















How to display recent commands?
Use signal handler: CTRL-C is the SIGINT signal
/* the signal handler function */
void handle_SIGINT() {
write(STDOUT_FILENO,buffer,strlen(buffer));
exit(0);
}
int main(int argc, char *argv[])
{
/* set up the signal handler */
struct sigaction handler;
handler.sa_handler = handle_SIGINT;
sigaction(SIGINT, &handler, NULL);
strcpy(buffer,"Caught <ctrl><c>\n");
/* wait for <control> <C> */
while (1);
return 0;
}
Operating System Concepts
4.35
Silberschatz, Galvin and Gagne ©2005
Methodology
 How to keep track of past commands?
 Limited-size buffer, why not use circular buffer?
 Modify setup() to store the current command which may overwrite
the oldest command in the buffer
 Implement SININT signal handler to display the 10 most recent
commands
Operating System Concepts
4.36
Silberschatz, Galvin and Gagne ©2005
Suggested Steps
 Step 1: implement setup()
 Step 2: execute the command from setup()
 Step 3: add the history feature
Operating System Concepts
4.37
Silberschatz, Galvin and Gagne ©2005
Submission
 Email to [email protected]
 All source files
 A readme file that describes each file, how to compile the file(s),
and how to run the file. If there is any problem running the file,
please state it here as well.
 Makefile may be a good option
 Due: 10/10/2006, Tuesday 1:30PM
Operating System Concepts
4.38
Silberschatz, Galvin and Gagne ©2005
Questions
Operating System Concepts
4.39
Silberschatz, Galvin and Gagne ©2005
End of Chapter 4