Operating systems cmpsc 473
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

Operating Systems CMPSC 473 PowerPoint PPT Presentation


  • 74 Views
  • Uploaded on
  • Presentation posted in: General

Operating Systems CMPSC 473. Threads September 16, 2010 - Lecture 7 Instructor: Bhuvan Urgaonkar. Overview of Process-related Topics. Done. How a process is born Parent/child relationship fork, clone, … How it leads its life Loaded: Executed CPU scheduling Context switching

Download Presentation

Operating Systems CMPSC 473

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Operating systems cmpsc 473

Operating SystemsCMPSC 473

Threads

September 16, 2010 - Lecture 7

Instructor: Bhuvan Urgaonkar


Overview of process related topics

Overview of Process-related Topics

Done

  • 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

Done (project 1)

today


The notion of a thread

The notion of a thread

code

  • Roughly, a flow of execution that is a basic unit of CPU utilization

    • E.g., a process, a KCP

data

heap

registers

stack

thread

A single-threaded process


Multi process applications

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 applications1

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

Approach #1: Writing a multi-process Application

In virtual

memory

code

data

code

data

code

data

code

data

  • E.g., a Web browser

heap

heap

heap

heap

registers

stack

registers

stack

registers

stack

registers

stack

URL parsing process

Network sending process

Network reception process

Interprets response, composes media

together and displays on browser screen


Approach 1 writing a multi process application1

Approach #1: Writing a multi-process Application

In virtual

memory

code

data

code

data

code

data

code

data

  • 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

heap

heap

heap

heap

registers

stack

registers

stack

registers

stack

registers

stack

URL parsing process

Network sending process

Network reception process

Interprets response, composes media

together and displays on browser screen


Approach 2 share code data heap

Approach #2: Share code, data, heap!

In virtual

memory

code

  • 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

heap

data

registers

stack

registers

stack

registers

stack

registers

stack

threads

URL parsing process

Network sending process

Network reception process

Interprets response, composes media

together and displays on browser screen


Old process address space

(Old) Process Address Space


New address space with threads

(New) Address Space with Threads

  • All threads in a process share the same address space


Implementing threads

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

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 tcb1

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

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

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


  • Login