Operating SystemsCMPSC 473

ThreadsSeptember 16, 2010 -

Lecture 7Instructor: Bhuvan

Urgaonkar

Overview of Process-related

Topics• How a process is born

– Parent/child relationship– fork, clone, …

• How it leads its life– Loaded: – Executed

• CPU scheduling• Context switching

• Where a process “lives”: Address space– OS maintains some info. for each process: PCB– Process = Address Space + PCB

• How processes request services from the OS– System calls

• How processes communicate• Some variants of processes: threads• How processes die

Done

Done (project 1)

Done

Done

today

code data

registersstack

heap

The notion of a thread

• Roughly, a flow of execution that is a basic unit of CPU utilization– E.g., a process, a KCP

thread

A single-threaded process

Multi-process Applications• Many applications need to do multiple activities

simultaneously– E.g., Web browser

• Parse requested URL and find IP address from DNS server• Use system calls to send request to some Web server• Receive response• Assemble response and display it

– Can you give another example?• Solution #1: Write multi-process application as

follows:– forks off multiple processes, each responsible for a

certain “flow of execution”• Programmer’s choice/decision

– Employ IPC mechanisms for these processes to communicate (coming up soon)• We already know about signals, how many have used pipes?

Shared memory?– Employ synchronization (ccoming up in a few lectures)

Multi-process Applications• Many applications need to do multiple activities

simultaneously– E.g., Web browser

• Parse requested URL and find IP address from DNS server• Use system calls to send request to some Web server• Receive response• Assemble response and display it

– Can you give another example?

• Approach #1: Write multi-process application as follows:– forks off multiple processes, each responsible for a

certain “flow of execution”• Programmer’s choice/decision

– Employ IPC mechanisms for these processes to communicate (coming up soon)• We already know about signals, how many have used pipes?

Other kinds of shared memory?– Employ synchronization (coming up in a few lectures)

Approach #1: Writing a multi-

process Application

• E.g., a Web browser

code data

registers stack

heap

URL parsing process

code data

registers stack

heap code data

registers stack

heap code data

registers stack

heap

Network sending processNetwork reception processInterprets response, composes mediatogether and displays on browser screen

In virtualmemory

Approach #1: Writing a multi-

process Application

• E.g., a Web browser • Potentially, lot of redundancy in code, data, and heap segments!

– Virtual memory wastage => More contention for precious RAM => More waiting for slow swap device => Reduction in computer’s throughput

• Also, TLB and cache contention between processes part of the same application

code data

registers stack

heap

URL parsing process

code data

registers stack

heap code data

registers stack

heap code data

registers stack

heap

Network sending processNetwork reception processInterprets response, composes mediatogether and displays on browser screen

In virtualmemory

Approach #2: Share code, data, heap!

• E.g., a Web browser• Share code, data, heap via shared memory mechanisms (coming up)

– Make them part of the same address space• Or let kernel or a user-library handle sharing of these parts of

the address spaces and let the programmer deal only with synchronization issues – Kernel vs. User threads

URL parsing processNetwork sending processNetwork reception processInterprets response, composes mediatogether and displays on browser screen

In virtualmemory

code data

registersstack

heap

registersstack registersstack registersstack

threads

(Old) Process Address Space

(New) Address Space with Threads

• All threads in a process share the same address space

Implementing Threads• Given what we know about processes, implementing threads is

“easy”• Idea: Break the PCB into two pieces:

– Thread-specific stuff: Processor state– Process-specific state: Address space and OS resources

(e.g., open files)

Thread Control Block (TCB)• TCB contains info on a single thread

– Just processor state and pointer to corresponding PCB

• PCB contains info on the containing process– Address space and OS resources, but NO processor state!

Thread Control Block (TCB)• TCBs are smaller and cheaper than PCBs

– Linux TCB (thread_struct) has 24 fields– Linux PCB (task_struct) has 106 fields

Context Switching• TCB is now the unit of a context switch

– Ready queue, wait queues, etc. now contain pointers to TCBs

– Context switch causes CPU state to be copied to/from the TCB

• Context switch between two threads of the same process– No need to change address space

• No TLB flush• Context switch between two threads of different processes

– Must change address space, sometimes invalidating cache– This will become relevant when we talk about virtual

memory

Prep. for Project 2

• Learn pthreads calls– Multi-threaded server and clients– https://computing.llnl.gov/tutorials/pthreads/#PthreadsAPI

– Use Solaris or Linux– Thread management

• pthread_create, pthread_exit– Threads synchronization

• Choose one of the following– pthread_join, pthread_detach– pthread_mutex_init, pthread_mutex_lock, pthread_mutex_unlock, pthread_mutex_destroy» We will study the “mutex” problem closely starting next week