Pintos: Threads Project

Slides:



Advertisements
Similar presentations
© 2004, D. J. Foreman 1 Scheduling & Dispatching.
Advertisements

The Pintos Instructional Operating System Kernel Ben Pfaff Nicira Networks Anthony Romano Stanford University Godmar.
R4 Dynamically loading processes. Overview R4 is closely related to R3, much of what you have written for R3 applies to R4 In R3, we executed procedures.
Resource management and Synchronization Akos Ledeczi EECE 354, Fall 2010 Vanderbilt University.
CS5270 Lecture 31 Uppaal, and Scheduling, and Resource Access Protocols CS 5270 Lecture 3.
Real-Time Library: RTX
Module R2 CS450. Next Week R1 is due next Friday ▫Bring manuals in a binder - make sure to have a cover page with group number, module, and date. You.
CSCC69: Operating Systems
Pintos: Threads Project Slides by: Vijay Kumar Updated by Godmar Back Presented by: Min Li.
Pintos: Threads Project Slides by: Vijay Kumar Updated by Godmar Back.
 A quantum is the amount of time a thread gets to run before Windows checks.  Length: Windows 2000 / XP: 2 clock intervals Windows Server systems: 12.
Introduction to Operating Systems – Windows process and thread management In this lecture we will cover Threads and processes in Windows Thread priority.
Home: Phones OFF Please Unix Kernel Parminder Singh Kang Home:
CPS110: Implementing threads/locks on a uni-processor Landon Cox.
Nachos Phase 1 Code -Hints and Comments
CS1550 Assignment 5 Multiprogramming Implementation notes Matt Craven.
CE Operating Systems Lecture 11 Windows – Object manager and process management.
Hardware process When the computer is powered up, it begins to execute fetch-execute cycle for the program that is stored in memory at the boot strap entry.
Multiprogramming. Readings r Silberschatz, Galvin, Gagne, “Operating System Concepts”, 8 th edition: Chapter 3.1, 3.2.
1 Review of Process Mechanisms. 2 Scheduling: Policy and Mechanism Scheduling policy answers the question: Which process/thread, among all those ready.
Pintos: Threads Project
CS140 Project 1: Threads Slides by Kiyoshi Shikuma.
Concurrency & Context Switching Process Control Block What's in it and why? How is it used? Who sees it? 5 State Process Model State Labels. Causes of.
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
CS 3204 Operating Systems Godmar Back Lecture 7. 12/12/2015CS 3204 Fall Announcements Project 1 due on Sep 29, 11:59pm Reading: –Read carefully.
Operating Systems CSE 411 CPU Management Sept Lecture 10 Instructor: Bhuvan Urgaonkar.
Processes, Threads, and Process States. Programs and Processes  Program: an executable file (before/after compilation)  Process: an instance of a program.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Processes and Threads.
Hardware process When the computer is powered up, it begins to execute fetch-execute cycle for the program that is stored in memory at the boot strap entry.
Managing Processors Jeff Chase Duke University. The story so far: protected CPU mode user mode kernel mode kernel “top half” kernel “bottom half” (interrupt.
1 Run-to-Completion Non-Preemptive Scheduler. 2 In These Notes... What is Scheduling? What is non-preemptive scheduling? Examples Run to completion (cooperative)
Slides created by: Professor Ian G. Harris Operating Systems  Allow the processor to perform several tasks at virtually the same time Ex. Web Controlled.
Introduction Contain two or more CPU share common memory and peripherals. Provide greater system throughput. Multiple processor executing simultaneous.
Unit 4: Processes, Threads & Deadlocks June 2012 Kaplan University 1.
Nachos Project 2 Lecturer: Hao-Hua Chu TA: Chun-Po Wang (Artoo) Date: 2008/10/14 Material Provided by Yuan-Hao Chang, Yung-Feng Lu.
Implementing Mutual Exclusion Andy Wang Operating Systems COP 4610 / CGS 5765.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Monitoring Dynamic IOC Installations Using the alive Record Dohn Arms Beamline Controls & Data Acquisition Group Advanced Photon Source.
CS140 Project Session Notes #1: Threads Haobo Xu, TA Fall Based on Ben Sapp’s slides Download these slides from
Multiprogramming. Readings r Chapter 2.1 of the textbook.
Operating System Overview
REAL-TIME OPERATING SYSTEMS
Processes and threads.
Process Tables; Threads
CS 6560: Operating Systems Design
Topics Covered What is Real Time Operating System (RTOS)
CS703 – Advanced Operating Systems
An Intro to Concurrent Versions System (CVS)
OPERATING SYSTEMS CS3502 Fall 2017
Round Robin Non-Preemptive Scheduler
Intro to Processes CSSE 332 Operating Systems
Version Control System
Process management Information maintained by OS for process management
Structure of Processes
ICS 143 Principles of Operating Systems
Process Tables; Threads
Scheduling.
Multithreading.
Lecture Topics: 11/1 General Operating System Concepts Processes
Implementing Mutual Exclusion
Process Control B.Ramamurthy 2/22/2019 B.Ramamurthy.
Amandeep Jawa Worker Bee Software
Implementing Mutual Exclusion
Chapter 3: Processes.
Unix Process Control B.Ramamurthy 4/11/2019 B.Ramamurthy.
Pintos: Threads Project
Real-Time Process Scheduling Concepts, Design and Implementations
CS703 – Advanced Operating Systems
Real-Time Process Scheduling Concepts, Design and Implementations
Chapter 3: Process Management
Presentation transcript:

Pintos: Threads Project Slides by: Vijay Kumar Updated for Fall 08 by Godmar Back Updated for Spring 09 by Peter Radics

Introduction to Pintos Simple OS for the 80x86 architecture Capable of running on real hardware We use bochs, qemu to run Pintos Provided implementation supports kernel threads, user programs and file system In the projects, strengthen support for these + implement support for virtual memory

Development Environment Log on to the Linux cluster remotely using SSH ssh –Y yourlogin@rlogin.cs.vt.edu (for trusted X11 forwarding) Need ssh client X11 server preferable, but not absolutely needed Use CVS for managing and merging code written by the team members keeping track of multiple versions of files

CVS Setup Start by choosing a code keeper for your group Keeper creates repository on ‘ap2’ Summary of commands to setup CVS ssh ap2 cd /shared/cs3204 mkdir Proj-keeper_pid setfacl --set u::rwx,g::---,o::--- Proj-keeper_pid # for all other group members do: setfacl -m u:member-pid:rwx Proj-keeper_pid setfacl -d --set u::rwx,g::---,o::--- Proj-keeper_pid # for all group members, including the keeper, do: setfacl -d -m u:member_pid:rwx Proj-keeper_pid cvs -d /shared/cs3204/Proj-keeper_pid init cd /home/courses/cs3204/pintos/pintos cvs -d /shared/cs3204/Proj-keeper_pid import -m "Imported sources" pintos foobar start

contains “working directory” Using CVS checkout & update import ssh transport Development machine in McB124 contains “working directory” commit Other useful CVS commands - diff - add - remove - update ap2.cs.vt.edu containing repository

CVS Jargon “Do an update” “Pull the latest” “Commit your stuff” “Push your changes” “Diff against the HEAD” “Diff against BASE” “outstanding diffs?” Bring your working directory in sync with the CVS repository to pick up and integrate changes other team members may have made. Upload your change to the CVS repository, allowing others to see them. May create a new revision if there were changes. Compare your working version to the version last checked in by any team member. Compare your working version to the version you last checked out. Any changes you’ve made are “outstanding” – group members can’t see them yet.

cvs –nq update -d cvs update – download latest changes from repository and merge into working copy ‘-n’ show me what’d do, don’t do it ‘-d’ pick up additional subdirectories (not done by default) Outputs: (nothing) – means you are up-to-date P or U – means there’s a newer version M – means you have outstanding diffs C – means there’s a newer version and you have outstanding diffs and they can’t be reconciled ? – this file is not part of the repository

Getting started with Pintos Set env variable CVS_RSH to /usr/bin/ssh export CVS_RSH=/usr/bin/ssh If you don’t, it will assume “rsh” which is not a supported service. Connection failures or timeouts will result. Check out a copy of the repository to directory ‘dir’ cvs -d :ext:your_pid@ap2.cs.vt.edu:/shared/cs3204/Proj-keeper_pid checkout -d dir pintos Add ~cs3204/bin to path add to .bash_profile export PATH=~cs3204/bin:$PATH Build pintos cd dir/src/threads make cd build pintos run alarm-multiple

Project 1 Overview Extend the functionality of a minimally functional thread system Implement Alarm Clock Priority Scheduling Including priority inheritance Advanced Scheduler

Pintos Thread System struct thread { tid_t tid; /* Thread identifier. */ enum thread_status status; /* Thread state. */ char name[16]; /* Name (for debugging purposes). */ uint8_t *stack; /* Saved stack pointer. */ int priority; /* Priority. */ struct list_elem allelem; /* List element for all-threads list.*/ /* Shared between thread.c and synch.c. */ struct list_elem elem; /* List element. */ You add more fields here as you need them. #ifdef USERPROG /* Owned by userprog/process.c. */ uint32_t *pagedir; /* Page directory. */ #endif /* Owned by thread.c. */ unsigned magic; /* Detects stack overflow. */ };

Pintos Thread System (contd…) Read threads/thread.c and threads/synch.c to understand How the switching between threads occur How the provided scheduler works How the various synchronizations primitives work

Alarm Clock Reimplement timer_sleep( ) in devices/timer.c without busy waiting /* Suspends execution for approximately TICKS timer ticks. */ void timer_sleep (int64_t ticks){ int64_t start = timer_ticks (); ASSERT (intr_get_level () == INTR_ON); while (timer_elapsed (start) < ticks) thread_yield (); } Implementation details Remove thread from ready list and put it back after sufficient ticks have elapsed

Priority Scheduler Ready thread with highest priority gets the processor When a thread is added to the ready list that has a higher priority than the currently running thread, immediately yield the processor to the new thread When threads are waiting for a lock, semaphore or a condition variable, the highest priority waiting thread should be woken up first Implementation details compare priority of the thread being added to the ready list with that of the running thread select next thread to run based on priorities compare priorities of waiting threads when releasing locks, semaphores, condition variables

Priority Based Scheduling MAX Only threads with the highest priority run If more than one, round-robin 6 Higher Priority 3 2 MIN

Using thread_yield() to implement preemption Current thread (“RUNNING”) is moved to READY state, added to READY list. Then scheduler is invoked. Picks a new READY thread from READY list. Case a): there’s only 1 READY thread. Thread is rescheduled right away Case b): there are other READY thread(s) b.1) another thread has higher priority – it is scheduled b.2) another thread has same priority – it is scheduled provided the previously running thread was inserted in tail of ready list. “thread_yield()” is a call you can use whenever you identify a need to preempt current thread. Exception: inside an interrupt handler, use “intr_yield_on_return()” instead RUNNING READY BLOCKED Process must wait for event Event arrived Scheduler picks process preempted 11/12/2018 CS 3204 Fall 2007

Priority Inversion Strict priority scheduling can lead to a phenomenon called “priority inversion” Supplemental reading: What really happened on the Mars Pathfinder? [comp.risks] Consider the following example where prio(H) > prio(M) > prio(L) H needs a lock currently held by L, so H blocks M that was already on the ready list gets the processor before L H indirectly waits for M (on Path Finder, a watchdog timer noticed that H failed to run for some time, and continuously reset the system)

Priority Donation When a high priority thread H waits on a lock held by a lower priority thread L, donate H’s priority to L and recall the donation once L releases the lock Implement priority donation for locks Handle the cases of multiple donations and nested donations

Multiple Priority Donations: Example static void a_thread_func (void *lock_) { struct lock *lock = lock_; lock_acquire (lock); msg ("Thread a acquired lock a."); lock_release (lock); msg ("Thread a finished."); } Medium Priority thread lock_acquire (&a); lock_acquire (&b); thread_create ("a", PRI_DEFAULT + 1, a_thread_func, &a); msg ("Main thread should have priority %d. Actual priority: %d.", PRI_DEFAULT + 1, thread_get_priority ()); thread_create ("b", PRI_DEFAULT + 2, b_thread_func, &b); msg ("Main thread should have priority %d. Actual priority: %d.", PRI_DEFAULT + 2, thread_get_priority ()); Low Priority thread static void b_thread_func (void *lock_) { struct lock *lock = lock_; lock_acquire (lock); msg ("Thread b acquired lock b."); lock_release (lock); msg ("Thread b finished."); } High Priority thread High via ‘b’ Low Medium via ‘a’

Nested Priority Donations: Example static void m_thread_func (void *locks_) { struct locks *locks = locks_; lock_acquire (locks->b); lock_acquire (locks->a); msg ("Medium thread should have priority %d. Actual priority: %d.", PRI_DEFAULT + 2, thread_get_priority ()); …} Medium Priority thread lock_acquire (&a); locks.a = &a; locks.b = &b; thread_create ("medium", PRI_DEFAULT + 1, m_thread_func, &locks); msg ("Low thread should have priority %d. Actual priority: %d.", PRI_DEFAULT + 1, thread_get_priority ()); thread_create ("high", PRI_DEFAULT + 2, h_thread_func, &b); msg ("Low thread should have priority %d. Actual priority: %d.", PRI_DEFAULT + 2, thread_get_priority ()); Low Priority thread static void h_thread_func (void *lock_) { struct lock *lock = lock_; lock_acquire (lock); …} High Priority thread High Medium Low via ‘b’ via ‘a’

Advanced Scheduler Implement Multi Level Feedback Queue Scheduler Priority donation not needed in the advanced scheduler – two implementations are not required to coexist Only one is active at a time Advanced Scheduler must be chosen only if ‘–mlfqs’ kernel option is specified Read section on 4.4 BSD Scheduler in the Pintos manual for detailed information Some of the parameters are real numbers and calculations involving them have to be simulated using integers. Write a fixed-point layer (header file)

Typesafe Fixed-Point Layer typedef struct { double re; double im; } complex_t; static inline complex_t complex_add(complex_t x, complex_t y) return (complex_t){ x.re + y.re, x.im + y.im }; } static inline double complex_real(complex_t x) return x.re; static inline double complex_imaginary(complex_t x) { return x.im; } complex_abs(complex_t x) return sqrt(x.re * x.re + x.im * x.im);

Suggested Order Alarm Clock Priority Scheduler easier to implement compared to the other parts other parts not dependent on this Priority Scheduler needed for implementing Priority Donation and Advanced Scheduler Priority Donation | Advanced Scheduler these two parts are independent of each other can be implemented in any order but only after Priority Scheduler is ready

Debugging your code printf, ASSERT, backtraces, gdb Running pintos under gdb Invoke pintos with the gdb option pintos --gdb -- run testname On another terminal invoke gdb pintos-gdb kernel.o Issue the command debugpintos All the usual gdb commands can be used: step, next, print, continue, break, clear etc Use the pintos debugging macros described in manual

Tips Read the relevant parts of the Pintos manual Read the comments in the source files to understand what a function does and what its prerequisites are Be careful with synchronization primitives disable interrupts only when absolutely needed use locks, semaphores and condition variables instead Beware of the consequences of the changes you introduce might affect the code that gets executed before the boot time messages are displayed, causing the system to reboot or not boot at all

Tips (contd…) Include ASSERTs to make sure that your code works the way you want it to Integrate your team’s code often to avoid surprises Use gdb to debug Make changes to the test files, if needed Test using qemu simulator and the –j option with bochs (introduces variability whereas default options run in reproducibility mode)

Grading & Deadline Tests – 50% Design – 50% All group members get the same grade Design – 50% data structures, algorithms, synchronization, rationale and coding standards Each group member will submit those individually: you can discuss them in the group, and ask each other questions – but must create write-up individually. Instructions will be posted on the website. Due Feb 23, 2009 by 11:59pm Good Luck!