Operating Systems, Assignment 2 Threads and Synchronization
|
|
- Marcia Barrett
- 5 years ago
- Views:
Transcription
1 Operating Systems, Assignment 2 Threads and Synchronization Responsible TA's: Zohar and Matan Assignment overview The assignment consists of the following parts: 1) Kernel-level threads package 2) Synchronization primitives: mutex, condition variable (Mesa and Hoare) 3) A monitor solution for a synchronization problem (of choosing grading slots) Task 0: Running xv6 As always, begin by downloading our revision of xv6, from the os152 repository: Open a shell, and traverse to the desired working directory. Execute the following command: git clone This will create a new folder that will contain all project s files. Build xv6 by calling: make. Run xv6 on top of QEMU by calling: make qemu. Kernel level threads (KLT) Kernel level threads (KLT) are implemented and managed by the kernel. Our implementation of KLT will be based on a new struct you must define called "thread". One key characteristic of threads is that all threads of the same process share the same virtual memory space. You will need to decide (for each field in the proc struct) if it will stay in proc or will move to the new struct thread. Be prepared to explain your choices in the frontal check. Thread creation is very similar to process creation in the fork system call but requires less initialization, for example, there is no need to create a new memory space. 1) We added a file named kthread.h which contains some constants, as well as the prototypes of the KLT package API functions. Review this file before you start. 2) Read this whole part thoroughly before you start implementing. 3) Understand what each of the fields in proc struct means to the process. Task 1: Kernel threads To implement kernel threads as stated above you will have to initially transfer the entire system to work with the new thread struct. After doing so every process will have 1 initial thread running in it. Once this part is done you will need to create the system calls that will allow the user to create and manage new threads.
2 Task 1.1: Moving to threads This task includes passing over a lot of kernel code and understanding any access to the proc field. Once this is done, figure out how to replace those accesses appropriately in order to replace the proc field with a new thread field. Another important issue is understanding how to synchronize changes in process state in a multi-cpu environment. Add a constant to proc.h called NTHREAD = 16. This will be the maximum number of threads each process can hold. Every CPU holds specific data, this data can be accessed by using the same field name in the code which will then link to the data of the current running CPU. Looking at proc.h you can see 2 such fields: A pointer to the cpu struct that contains CPU information and another pointer to a proc struct which is how you access the current running process. You must change it so that the CPU will be able to access the thread struct of the currently running thread. The CPU knows the location of this data using the gs register so you need to set the memory address of the new thread field relative to the gs register of the current CPU. Below the cpu struct you can see how this is done to proc and cpu, try to explain why proc is at gs + 4. As you have seen in assignment 1, XV6 implements scheduling policy that goes over the list of processes and chooses the next RUNNABLE process in the array. You are expected to change the scheduling so it will run over all the available threads of a specific process before proceeding to the next process. This is similar to the original scheduling policy, just over threads. Handling a multi-cpu environment means that you will have to think about handling shared process information. For example: growproc is a function in proc.c which is responsible for retrieving more memory when the process asks for it. If not protected, 2 CPUs running threads of the same process calling this function may override the sz parameter and cause issues in the system. Consider synchronizing those shared process fields when they are accessed. Be prepared to explain why you did or didn't synchronize those accesses. Expected behavior of existing system calls: 1) Fork should only duplicate the calling thread, if other threads exist in the process they will not exist in the new process 2) Exec should start running on a single thread of the new process. Notice that in a multi-cpu environment a thread might be still running on one CPU while another thread of the same process, running on another CPU, is attempting to perform exec. The thread performing exec should "tell" other threads of the same process to destroy themselves upon exit from user mode and only then complete the exec task. Hint: You can review the code that is performed when the proc->killed field is set and write your implementation similarly. 3) Exit should kill the process and all of its threads, remember while a thread running on one CPU is executing exit, others threads of the same process might still be running. Task 1.2: Thread system calls In this part of the assignment you will add system calls that will allow applications to create kernel threads. Implement the following new system calls: int kthread_create( void*(*start_func)(), void* stack, uint stack_size );
3 Calling kthread_create will create a new thread within the context of the calling process. The newly created thread state will be runnable. The caller of kthread_create must allocate a user stack for the new thread to use, whose size is defined by the MAX_STACK_SIZE macro in proc.h. This does not replace the kernel stack for the thread. start_func is a pointer to the entry function, which the thread will start executing. Upon success, the identifier of the newly created thread is returned. In case of an error, a non-positive value is returned. The kernel thread creation system call on real Linux does not receive a user stack pointer. In Linux the kernel allocates the memory for the new thread stack. Since we didn t teach memory management yet, you will need to create the stack in user mode and send a pointer to its end in the system call. (Allocating the stack in the kernel, which we don't do in this assignment, means you will later need to manage virtual memory addresses when a stack is removed or created.) int kthread_id(); Upon success, this function returns the caller thread's id. In case of error, a non-positive error identifier is returned. Remember, thread id and process id are not identical. void kthread_exit(); This function terminates the execution of the calling thread. If called by a thread (even the main thread) while other threads exist within the same process, it shouldn t terminate the whole process. If it is the last running thread, process should terminate. Each thread must explicitly call kthread_exit() in order to terminate normally. int kthread_join(int thread_id); This function suspends the execution of the calling thread until the target thread, indicated by the argument thread_id, terminates. If the thread has already exited, execution should not be suspended. If successful, the function returns zero. Otherwise, -1 should be returned to indicate an error. It is recommended that you write a user program to test all the system calls stated above. Task 2: Synchronization primitives In this task we will implement two types of synchronization primitives: mutex and condition variable. The mutex will be implemented in the kernel, and the implementation of condition variables will be done as a user library (implemented in user space), and will be based on mutexes. Your next task (task 3) will be to implement two different types of monitors (another synchronization mechanism). Each of the types is based on a different implementation of an appropriate condition variable. Hence, in this task, you are required to implement two types of condition variable: Mesa and Hoare. Before implementing this task you should do the following: 1) Read about mutexes and condition variables in POSIX. Our implementation will emulate the behavior and API of pthread_mutex and pthread_cond. A nice tutorial is provided by Lawrence Livermore National Laboratory. 2) Examine the implementation of spinlocks in xv6's kernel (for example, the scheduler uses a spinlock). Spinlocks are used in xv6 in order to synchronize kernel code. Your task is to implement the required synchronization primitives as a kernel service to
4 applications, via system calls. Locking and releasing can be based on the implementation of spinlocks to synchronize access to the data structures which you will create to support mutexes and condition variables. 3) Read about monitors and specifically about Hoare vs. Mesa monitors. A good tutorial can be found at Monitor, Monitor Types. Task 2.1: mutex Quoting from the pthreads tutorial by Lawrence Livermore National Laboratory: Mutex is an abbreviation for "mutual exclusion". Mutex variables are one of the primary means of implementing thread synchronization and for protecting shared data when multiple writes occur. A mutex variable acts like a "lock" protecting access to a shared data resource. The basic concept of a mutex, as used in pthreads, is that only one thread can lock (or own) a mutex variable at any given time. Thus, even if several threads try to lock a mutex only one thread will be successful, and all other threads will get blocked until the mutex becomes available. Mutex differs from a binary semaphore in its unlock semantics - only the thread which locked the mutex is allowed to unlock it, unlike binary semaphores on which any thread can perform up. Examine pthreads' implementation, and define the type kthread_mutex_t inside the xv6 kernel to represent a mutex object. You can use a global static array to hold the mutex objects in the system. The size of the array should be defined by the macro MAX_MUTEXES. The API for mutex functions is as follows: int kthread_mutex_alloc(); Allocates a mutex object and initializes it; the initial state should be unlocked. The function should return the ID of the initialized mutex, or -1 upon failure. int kthread_mutex_dealloc( int mutex_id ); De-allocates a mutex object which is no longer needed. The function should return 0 upon success and -1 upon failure (for example, if the given mutex is currently locked). int kthread_mutex_lock( int mutex_id ); This function is used by a thread to lock the mutex specified by the argument mutex_id. If the mutex is already locked by another thread, this call will block the calling thread (change the thread state to BLOCKED) until the mutex is unlocked. int kthread_mutex_unlock( int mutex_id ); This function unlocks the mutex specified by the argument mutex_id if called by the owning thread, and if there are any blocked threads, the longest waiting thread will acquire the mutex. This is called a fair mutex. An error code will be returned if the mutex was already unlocked, or if the mutex is owned by another thread. The mutex may be owned by one thread and unlocked by another! int kthread_mutex_yieldlock( int mutex_id1, int mutex_id2);
5 Hoare condition variable requires the ability of one thread to yield a locked mutex directly to another thread. In order to do so, an appropriate system call is required. This function will provide this functionality by passing the lock mutex_id1 (locked by the calling thread) to one of the threads that are waiting on the lock mutex_id2. The call should pass both locks directly to one of the threads waiting on mutex_id2, and return 0 upon success. If the caller doesn t hold mutex_id1 it should fail and return -1. If there are no threads waiting on mutex_id2, the function should just take both locks from the caller (and return 0). Implementation notes: In all the above functions, the value 0 should be returned upon success, and a negative value upon failure. No busy waiting should be used whatsoever, except for synchronizing access to the mutex array using short-time waiting in spinlock. You are required to implement the exact API detailed here and in kthread.h. The graders will run automatic tests to validate your implementation. You are allowed to add additional functions if you find it necessary for the implementation of the conditional variables or the monitors. However, if you choose to do so, be ready to justify your decision in your frontal meeting with the grader. Task 2.2: Condition variable A condition variable is a synchronization mechanism that allows threads to suspend execution and relinquish the processor until some condition is satisfied. The basic operations on condition variables (CV) are: Wait on the CV, suspending the thread's execution until another thread signals the CV and wakes up the waiting thread. Signal a thread that is waiting on the CV. A CV must always have an associated mutex, to avoid a race condition where a thread prepares to wait on a CV and another thread signals the CV just before the first thread actually starts waiting on it. When wait is called, it receives the mutex (in a locked state) as an argument and releases it atomically when the thread starts waiting, and locks it once again after that thread has received a signal (just before it returns from wait ). Mesa vs. Hoare: There is a delicate difference between the Mesa and Hoare implementations of CVs. In a Mesa CV when a thread calls signal it is guaranteed that the function will return immediately, and one of the threads (if any) waiting for the CV will receive the signal. However, the thread that received the signal may may have to also wait for the mutex associated with the CV in order to continue running. In Hoare s CV, the signaler yields the mutex. I.e., once a thread sends a signal, it gives up control on the mutex associated with the CV, and passes it directly to the signaled thread. Hence, the signaler might be blocked for a while, until it regains control on that mutex. However, the thread receiving the signal is guaranteed to run immediately once it receives a signal, since the mutex is also passed to it directly. It is also guaranteed that after the thread has received the signal the required condition for which it waits holds (Why? Why isn t it the
6 situation in the Mesa implementation?). For further explanations and examples, read about Monitor Types. Implementation: Given a mutex, it is possible to implement a condition-variable library in user space. You are required to implement two such libraries, according to the API s in mesa_cond.h and hoare_cond.h. Again, it is important to follow the API exactly in order to pass the automatic tests. First define the type mesa_cond_t in mesa_cond.h, and the type hoare_cond_t in hoare_cond.h. The API for Mesa condition variable functions is as follows: mesa_cond_t * mesa_cond_alloc(); Allocates a new condition variable and initializes it. The function should return a pointer to the initialized CV, or 0 upon failure. int mesa_cond_dealloc(mesa_cond_t * cond); De-allocates the condition variable object cond, which is no longer needed. Return 0 upon success and -1 upon failure (e.g., if there are threads waiting on cond). int mesa_cond_wait(mesa_cond_t * cond, int mutex_id); Blocks the calling thread until it is signaled. This routine should be called while mutex is locked by the calling thread, and it will atomically release the mutex and put the thread to sleep. After a signal is received by the thread, it is awakened in a state where the mutex is locked for use by it. The thread is then responsible for unlocking the mutex when the thread is finished with it. int mesa_cond_signal(mesa_cond_t * cond); This routine is used to signal (wake up) another thread that is waiting on the condition variable. It should be called after the relevant mutex is locked, and it is the code's responsibility to unlock the mutex afterwards (so that the signaled thread will be able to complete its mesa_cond_wait call). The API for Hoare condition variable functions is as follows: hoare _cond_t * hoare _cond_alloc(); Exactly the same as mesa_cond_alloc(). int hoare _cond_dealloc(hoare _cond_t * cond); Exactly the same as mesa_cond_dealloc(). int hoare_cond_wait(hoare _cond_t * cond, int mutex_id); Similar to mesa_cond_wait. The only difference should be that once some thread calls signal it also passes the mutex lock directly to the thread receiving the signal, hence it will run immediately after the signal is sent (this does not allow a third thread to lock the mutex
7 between the call of signal and the awakening from wait ). Return 0 upon success and -1 upon failure. int hoare _cond_signal(hoare _cond_t * cond, int mutex_id); Similar to mesa_cond_signal. Here the user should also pass a mutex_id, which is the mutex that should be passed from the signaler thread to the signaled thread directly. It must be called after the relevant mutex is locked. A call of this function may block the caller until the mutex is released by the signaled thread and locked again by this function, before it returns. Return 0 upon success and -1 upon failure. Task 3: A Monitor solution for a Synchronization problem Consider the following synchronization problem: in BGU Operating Systems course, students have to register grading slots in order to receive a grade for their assignment. Since the grader doesn t know how many students want to be graded, and she doesn t want slots to remain empty, she publishes only a few slots at a time. She waits for all slots to be taken by students and only when all slots are taken she publishes a few more slots. This process continues until all students are done taking slots. First, you are required to implement two types of monitors: mesa_slots_ monitor and hoare_slots_ monitor, which will implement the same API by the use of different condition variables (Mesa and Hoare, correspondingly). Task 3.1: Monitors The API for the slots monitors is as follows: mesa/hoare_slots _monitor_t* mesa/hoare slots_mesa_monitor_alloc(); Allocates a new monitor. int mesa/hoare_slots_monitor_dealloc(slots_mesa_monitor_t* monitor); Deallocates the given monitor. int mesa/hoare_slots_monitor_addslots(slots_mesa_monitor_t* monitor,int n); Add n slots, and notify the waiting students that there are free slots (so if some students are waiting for slots they will take it and continue). If the current number of slots is greater than zero, this function should block the caller until all slots are taken or until all students are done taking their slots. int mesa/hoare_slots_monitor_takeslot(slots_mesa_monitor_t*); Take one slot. If there are no slots, this function should block the caller until there is a free slot. If the last slot is taken, it should send a signal to notify that there are no more slots (so the grader will add more). Otherwise, if there are more free slots, notify the other students that there are free slots which may result in a chain of signals from one student to another until all slots are taken. int mesa/hoare_slots_monitor_stopadding(slots_mesa_monitor_t*); Should notify the grader to stop adding slots.
8 Implementation notes: Make sure that you implement the API twice: once for each type of monitor. The different types of monitors must use the different types of condition variables. The returned integer for all the above functions (except alloc) should be 0 upon success and -1 upon failure. Task 3.2: Simulation You are required to implement user programs called slots_mesa and slots_hoare that will simulate this scenario: once with the mesa slots monitor and once with a hoare slots monitor. Each version needs to be implemented with the appropriate monitor as mentioned above. Your programs should receive as parameters: m - The number of students. n - The number of slots published by the grader each time. A new thread will be created for the grader itself and for each student. The program should let the graders-thread add n slots at a time, and each of the m student-threads take a slot. Then the main thread of the program should: 1. Wait until all student threads are done. 2. Notify the grader thread to stop adding slots. 3. Wait for the grader thread to exit, and return. Implementation notes: Make sure you understand the difference between the Hoare and Mesa implementations of monitors and condition variables. You should be able to explain to the grader how these differences are reflected in your program. Print some outputs that will demonstrate the sequence of operations done by the different threads. Simulation with KLT on multiple CPUs The current configuration in the Makefile defines that xv6 runs on a single CPU. Change xv6's configuration to work with 2 CPUs instead of 1. Note that changes should be made to the Makefile to support multi-core. You may have noticed that QEMU uses another piece of software called KVM. KVM (Kernel based virtual machine) is a virtualization infrastructure for the Linux kernel. KVM supports native virtualization on processors with hardware virtualization extensions [Wikipedia]. For the KVM to exploit multiple CPUs on a multi-core computer it s necessary to set the CPU virtualization flag in the BIOS (most modern
9 CPUs support it). Labs 302/34 and 142/90 have these settings enabled, additional labs might also have them but this is not guaranteed. If you work on your own computer you ll have to apply the mentioned settings in your computer's BIOS. If you are running Linux on a virtual machine it might be a problem (nested virtualization) and we didn t test it in such a configuration. Note that except for the multi-core support (and some other features which we don t use for now) QEMU and KVM are functioning without the BIOS modifications. You can develop on any computer which has QEMU installed, and then test on the labs computers which support hardware virtualization. Submission guidelines Assignment due date: 23:59, 10/05/ /05/2015 Make sure that your Makefile is properly updated and that your code compiles with no warnings whatsoever. We strongly recommend documenting your code changes with remarks these are often handy when discussing your code with the graders. Due to our constrained resources, assignments are only allowed in pairs. Please note this important point and try to match up with a partner as soon as possible. Submissions are only allowed through the submission system. To avoid submitting a large number of xv6 builds you are required to submit a svn patch (i.e. a file which patches the original xv6 and applies all your changes). Tip: although graders will only apply your latest patch file, the submission system supports multiple uploads. Use this feature often and make sure you upload patches of your current work even if you haven t completed the assignment. Finally, you should note that graders are instructed to examine your code on lab computers only (!) - Test your code on lab computers prior to submission!!! Open a clean folder, download a clean version of xv6 from svn and apply your patch.
OPERATING SYSTEMS, ASSIGNMENT 2 KERNEL THREADS IN XV6, SYNCHRONIZATION
OPERATING SYSTEMS, ASSIGNMENT 2 KERNEL THREADS IN XV6, SYNCHRONIZATION SUBMISSION DATE: 9/5/2013 Task 0: Downloading xv6 Begin by downloading our revision of xv6, from the os112 svn repository: Open a
More informationOPERATING SYSTEMS - ASSIGNMENT 2 SYNCHRONIZATION & THREADS
OPERATING SYSTEMS - ASSIGNMENT 2 SYNCHRONIZATION & THREADS Introduction In this assignment we will add synchronization tools\methods to the xv6 kernel. We start with a simple binary semaphore and then
More informationOPERATING SYSTEMS ASSIGNMENT 2 SIGNALS, USER LEVEL THREADS AND SYNCHRONIZATION
OPERATING SYSTEMS ASSIGNMENT 2 SIGNALS, USER LEVEL THREADS AND SYNCHRONIZATION Responsible TAs: Vadim Levit & Benny Lutati Introduction In this assignment we will extend xv6 to support a simple signal
More informationOPERATING SYSTEMS ASSIGNMENT 3 MEMORY MANAGEMENT
OPERATING SYSTEMS ASSIGNMENT 3 MEMORY MANAGEMENT Introduction Memory management and memory abstraction is one of the most important features of any operating system. In this assignment we will examine
More informationOperating Systems Synchronization and Signals
OS162: Assignment 2 Operating Systems Synchronization and Signals TAs in charge Vadim Levit levitv@post.bgu.ac.il Benny Lutati bennyl@post.bgu.ac.il Due Date: 30.04.2016 1 Introduction The assignment main
More informationIntroduction. Xv6 memory
O P E R A T I N G S Y S T E M S A S S I G N M E N T 3 M E M O R Y M A N A G E M E N T Introduction Memory management and memory abstraction is one of the most important features of any operating system.
More informationOPERATING SYSTEMS ASSIGNMENT 4 XV6 file system
OPERATING SYSTEMS ASSIGNMENT 4 XV6 file system Introduction In most systems the main weakness of the file system stems from the data access time, which is much longer than accessing the memory. For certain
More informationOPERATING SYSTEMS ASSIGNMENT 4 FILE SYSTEM
OPERATING SYSTEMS ASSIGNMENT 4 FILE SYSTEM Introduction The File system is an integral part of every operating system. The use of files enables the user to save persistent data. Files can also be used
More informationOPERATING SYSTEMS, ASSIGNMENT 4 FILE SYSTEM
OPERATING SYSTEMS, ASSIGNMENT 4 FILE SYSTEM SUBMISSION DATE: 15/06/2014 23:59 In this assignment you are requested to extend the file system of xv6. xv6 implements a Unix-like file system, and when running
More informationCS533 Concepts of Operating Systems. Jonathan Walpole
CS533 Concepts of Operating Systems Jonathan Walpole Introduction to Threads and Concurrency Why is Concurrency Important? Why study threads and concurrent programming in an OS class? What is a thread?
More informationProject 3 Improved Process Management
Project 3 Improved Process Management Introduction This project will modernize process management in xv6. All process management will be impacted. New console control sequences will be implemented to support
More informationOPERATING SYSTEMS ASSIGNMENT 4 FILE SYSTEMS
OPERATING SYSTEMS ASSIGNMENT 4 FILE SYSTEMS The xv6 file system provides Unix-like files, directories, and pathnames, and stores its data on an IDE disk for persistence. The file-system addresses several
More informationConcurrency, Thread. Dongkun Shin, SKKU
Concurrency, Thread 1 Thread Classic view a single point of execution within a program a single PC where instructions are being fetched from and executed), Multi-threaded program Has more than one point
More informationProblem Set 2. CS347: Operating Systems
CS347: Operating Systems Problem Set 2 1. Consider a clinic with one doctor and a very large waiting room (of infinite capacity). Any patient entering the clinic will wait in the waiting room until the
More informationOperating Systems (234123) Spring (Homework 3 Wet) Homework 3 Wet
Due date: Monday, 4/06/2012 12:30 noon Teaching assistants in charge: Operating Systems (234123) Spring-2012 Homework 3 Wet Anastasia Braginsky All emails regarding this assignment should be sent only
More informationCMSC421: Principles of Operating Systems
CMSC421: Principles of Operating Systems Nilanjan Banerjee Assistant Professor, University of Maryland Baltimore County nilanb@umbc.edu http://www.csee.umbc.edu/~nilanb/teaching/421/ Principles of Operating
More informationDealing with Issues for Interprocess Communication
Dealing with Issues for Interprocess Communication Ref Section 2.3 Tanenbaum 7.1 Overview Processes frequently need to communicate with other processes. In a shell pipe the o/p of one process is passed
More informationCS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring Lecture 8: Semaphores, Monitors, & Condition Variables
CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004 Lecture 8: Semaphores, Monitors, & Condition Variables 8.0 Main Points: Definition of semaphores Example of use
More informationCS-537: Midterm Exam (Spring 2001)
CS-537: Midterm Exam (Spring 2001) Please Read All Questions Carefully! There are seven (7) total numbered pages Name: 1 Grading Page Points Total Possible Part I: Short Answers (12 5) 60 Part II: Long
More informationIntroduction. This project will focus primarily on processes.
Project 2 Processes Introduction This project will focus primarily on processes. In this project, you will become familiar with: 1. Locks for kernel-level data structures; concurrency. 2. Implementing
More informationProcesses and Threads. Processes and Threads. Processes (2) Processes (1)
Processes and Threads (Topic 2-1) 2 홍성수 Processes and Threads Question: What is a process and why is it useful? Why? With many things happening at once in a system, need some way of separating them all
More informationCS355 Hw 4. Interface. Due by the end of day Tuesday, March 20.
Due by the end of day Tuesday, March 20. CS355 Hw 4 User-level Threads You will write a library to support multiple threads within a single Linux process. This is a user-level thread library because the
More informationCS 333 Introduction to Operating Systems. Class 3 Threads & Concurrency. Jonathan Walpole Computer Science Portland State University
CS 333 Introduction to Operating Systems Class 3 Threads & Concurrency Jonathan Walpole Computer Science Portland State University 1 Process creation in UNIX All processes have a unique process id getpid(),
More informationOperating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst
Operating Systems CMPSCI 377 Spring 2017 Mark Corner University of Massachusetts Amherst What is a Monitor? Ties data and the synchronization operations together Monitors guarantee mutual exclusion, i.e.,
More informationDeadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018
Deadlock and Monitors CS439: Principles of Computer Systems September 24, 2018 Bringing It All Together Processes Abstraction for protection Define address space Threads Share (and communicate) through
More informationIntroduction to PThreads and Basic Synchronization
Introduction to PThreads and Basic Synchronization Michael Jantz, Dr. Prasad Kulkarni Dr. Douglas Niehaus EECS 678 Pthreads Introduction Lab 1 Introduction In this lab, we will learn about some basic synchronization
More informationInterprocess Communication By: Kaushik Vaghani
Interprocess Communication By: Kaushik Vaghani Background Race Condition: A situation where several processes access and manipulate the same data concurrently and the outcome of execution depends on the
More informationW4118 Operating Systems. Instructor: Junfeng Yang
W4118 Operating Systems Instructor: Junfeng Yang Outline Semaphores Producer-consumer problem Monitors and condition variables 2 Semaphore motivation Problem with lock: mutual exclusion, but no ordering
More informationOperating Systems. Operating Systems Summer 2017 Sina Meraji U of T
Operating Systems Operating Systems Summer 2017 Sina Meraji U of T More Special Instructions Swap (or Exchange) instruction Operates on two words atomically Can also be used to solve critical section problem
More informationCS 385 Operating Systems Fall 2011 Homework Assignment 5 Process Synchronization and Communications
CS 385 Operating Systems Fall 2011 Homework Assignment 5 Process Synchronization and Communications Due: Friday December 2 at 8:00 P.M. via Blackboard Overall Assignment Man Pages For this assignment,
More informationCSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs
CSE 451: Operating Systems Winter 2005 Lecture 7 Synchronization Steve Gribble Synchronization Threads cooperate in multithreaded programs to share resources, access shared data structures e.g., threads
More informationConcurrent Server Design Multiple- vs. Single-Thread
Concurrent Server Design Multiple- vs. Single-Thread Chuan-Ming Liu Computer Science and Information Engineering National Taipei University of Technology Fall 2007, TAIWAN NTUT, TAIWAN 1 Examples Using
More informationCS3210: Coordination. Tim Andersen
1 CS3210: Coordination Tim Andersen 2 Administrivia Lab5 out, due November 21st Demo day: 8 min for demo, 2 min for Q&A Final project (write up): December 2nd 3 Today's plan Context switching (i.e., swtch
More informationEECS 482 Introduction to Operating Systems
EECS 482 Introduction to Operating Systems Winter 2018 Harsha V. Madhyastha Monitors vs. Semaphores Monitors: Custom user-defined conditions Developer must control access to variables Semaphores: Access
More informationRecap: Thread. What is it? What does it need (thread private)? What for? How to implement? Independent flow of control. Stack
What is it? Recap: Thread Independent flow of control What does it need (thread private)? Stack What for? Lightweight programming construct for concurrent activities How to implement? Kernel thread vs.
More informationSynchronization. CS 475, Spring 2018 Concurrent & Distributed Systems
Synchronization CS 475, Spring 2018 Concurrent & Distributed Systems Review: Threads: Memory View code heap data files code heap data files stack stack stack stack m1 m1 a1 b1 m2 m2 a2 b2 m3 m3 a3 m4 m4
More information1. Introduction. 2. Project Submission and Deliverables
Spring 2018 Programming Project 2 Due 11:59 PM, Wednesday, 3/21/18 (3/21 is the Wednesday after Spring Break, so if you don t want to work on the program over break or save all the work for those last
More informationChapter 4: Threads. Overview Multithreading Models Thread Libraries Threading Issues Operating System Examples Windows XP Threads Linux Threads
Chapter 4: Threads Overview Multithreading Models Thread Libraries Threading Issues Operating System Examples Windows XP Threads Linux Threads Chapter 4: Threads Objectives To introduce the notion of a
More informationTCSS 422: OPERATING SYSTEMS
TCSS 422: OPERATING SYSTEMS OBJECTIVES Introduction to threads Concurrency: An Introduction Wes J. Lloyd Institute of Technology University of Washington - Tacoma Race condition Critical section Thread
More informationProject 2: Part 1: RPC and Locks
Project 2: Part 1: RPC and Locks Due: 11:59PM Thursday, October 14, 2010 1 Introduction In this series of labs, you will implement a fully functional distributed file server with the Frangipani architecture
More informationSynchroniza+on II COMS W4118
Synchroniza+on II COMS W4118 References: Opera+ng Systems Concepts (9e), Linux Kernel Development, previous W4118s Copyright no2ce: care has been taken to use only those web images deemed by the instructor
More informationCS510 Advanced Topics in Concurrency. Jonathan Walpole
CS510 Advanced Topics in Concurrency Jonathan Walpole Threads Cannot Be Implemented as a Library Reasoning About Programs What are the valid outcomes for this program? Is it valid for both r1 and r2 to
More informationCS 333 Introduction to Operating Systems. Class 3 Threads & Concurrency. Jonathan Walpole Computer Science Portland State University
CS 333 Introduction to Operating Systems Class 3 Threads & Concurrency Jonathan Walpole Computer Science Portland State University 1 The Process Concept 2 The Process Concept Process a program in execution
More informationREVIEW OF COMMONLY USED DATA STRUCTURES IN OS
REVIEW OF COMMONLY USED DATA STRUCTURES IN OS NEEDS FOR EFFICIENT DATA STRUCTURE Storage complexity & Computation complexity matter Consider the problem of scheduling tasks according to their priority
More informationConcurrent Programming Lecture 10
Concurrent Programming Lecture 10 25th September 2003 Monitors & P/V Notion of a process being not runnable : implicit in much of what we have said about P/V and monitors is the notion that a process may
More informationProcesses (Intro) Yannis Smaragdakis, U. Athens
Processes (Intro) Yannis Smaragdakis, U. Athens Process: CPU Virtualization Process = Program, instantiated has memory, code, current state What kind of memory do we have? registers + address space Let's
More informationProject 3-2. Mutex & CV
SSE3044 Introduction to Operating Systems Prof. Jinkyu Jeong Project 3-2. Mutex & CV 2018.05.30 (Wed.) TAs 이규선 (gyusun.lee@csl.skku.edu) / 안민우 (minwoo.ahn@csl.skku.edu) Project Plan Total 4 projects 1)
More informationLecture 8: September 30
CMPSCI 377 Operating Systems Fall 2013 Lecture 8: September 30 Lecturer: Prashant Shenoy Scribe: Armand Halbert 8.1 Semaphores A semaphore is a more generalized form of a lock that can be used to regulate
More informationLast class: Today: Thread Background. Thread Systems
1 Last class: Thread Background Today: Thread Systems 2 Threading Systems 3 What kind of problems would you solve with threads? Imagine you are building a web server You could allocate a pool of threads,
More informationConcurrency: a crash course
Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Concurrency: a crash course Concurrent computing Applications designed as a collection of computational units that may execute
More informationCMSC 330: Organization of Programming Languages
CMSC 330: Organization of Programming Languages Multithreading Multiprocessors Description Multiple processing units (multiprocessor) From single microprocessor to large compute clusters Can perform multiple
More informationSemaphores. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University
Semaphores Jinkyu Jeong (jinkyu@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu EEE3052: Introduction to Operating Systems, Fall 2017, Jinkyu Jeong (jinkyu@skku.edu) Synchronization
More informationCS Operating Systems
CS 4500 - Operating Systems Module 4: The Producer-Consumer Problem and Solution Methods Stanley Wileman Department of Computer Science University of Nebraska at Omaha Omaha, NE 68182-0500, USA June 3,
More informationCS Operating Systems
CS 4500 - Operating Systems Module 4: The Producer-Consumer Problem and Solution Methods Stanley Wileman Department of Computer Science University of Nebraska at Omaha Omaha, NE 68182-0500, USA June 3,
More informationHint #1. Define a syscall
PC 5 System call Exercice Clone the git repository git clone http://gitlab.montefiore.ulg.ac.be/info0940/kernel-4.4.50.git Make a "PC4" branch Add a sys_forkexec system call It is the equivalent of calling
More informationCondition Variables. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University
Condition Variables Jinkyu Jeong (jinkyu@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu EEE3052: Introduction to Operating Systems, Fall 2017, Jinkyu Jeong (jinkyu@skku.edu)
More informationPage 1. Goals for Today" Atomic Read-Modify-Write instructions" Examples of Read-Modify-Write "
Goals for Today" CS162 Operating Systems and Systems Programming Lecture 5 Semaphores, Conditional Variables" Atomic instruction sequence Continue with Synchronization Abstractions Semaphores, Monitors
More informationThe Process Abstraction. CMPU 334 Operating Systems Jason Waterman
The Process Abstraction CMPU 334 Operating Systems Jason Waterman How to Provide the Illusion of Many CPUs? Goal: run N processes at once even though there are M CPUs N >> M CPU virtualizing The OS can
More informationLecture 5: Synchronization w/locks
Lecture 5: Synchronization w/locks CSE 120: Principles of Operating Systems Alex C. Snoeren Lab 1 Due 10/19 Threads Are Made to Share Global variables and static objects are shared Stored in the static
More informationLAB 2: PROCESS SYNCHRONIZATION IN XV6
Fall 2018 - CS/COE 1550 LAB 2: PROCESS SYNCHRONIZATION IN XV6 In this lab, you will implement a synchronization solution using locks and condition variables to guarantee a specific execution ordering among
More informationDepartment of Computer Science. COS 122 Operating Systems. Practical 3. Due: 22:00 PM
Department of Computer Science COS 122 Operating Systems Practical 3 Due: 2018-09-13 @ 22:00 PM August 30, 2018 PLAGIARISM POLICY UNIVERSITY OF PRETORIA The Department of Computer Science considers plagiarism
More informationCSE 451: Operating Systems Winter Lecture 7 Synchronization. Hank Levy 412 Sieg Hall
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization Hank Levy Levy@cs.washington.edu 412 Sieg Hall Synchronization Threads cooperate in multithreaded programs to share resources, access shared
More information1. Overview This project will help you understand address spaces and virtual memory management.
Project 2--Memory Worth: 12 points Assigned: Due: 1. Overview This project will help you understand address spaces and virtual memory management. In this project, you will implement an external pager,
More informationOperating Systems. Synchronization
Operating Systems Fall 2014 Synchronization Myungjin Lee myungjin.lee@ed.ac.uk 1 Temporal relations Instructions executed by a single thread are totally ordered A < B < C < Absent synchronization, instructions
More informationCS 31: Introduction to Computer Systems : Threads & Synchronization April 16-18, 2019
CS 31: Introduction to Computer Systems 22-23: Threads & Synchronization April 16-18, 2019 Making Programs Run Faster We all like how fast computers are In the old days (1980 s - 2005): Algorithm too slow?
More informationDeadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018
Deadlock and Monitors CS439: Principles of Computer Systems February 7, 2018 Last Time Terminology Safety and liveness Atomic Instructions, Synchronization, Mutual Exclusion, Critical Sections Synchronization
More informationProcesses. Johan Montelius KTH
Processes Johan Montelius KTH 2017 1 / 47 A process What is a process?... a computation a program i.e. a sequence of operations a set of data structures a set of registers means to interact with other
More informationChapter 6: Process Synchronization
Chapter 6: Process Synchronization Objectives Introduce Concept of Critical-Section Problem Hardware and Software Solutions of Critical-Section Problem Concept of Atomic Transaction Operating Systems CS
More informationProject 2 : User Level Thread Library Operating Systems September 19, 2003
Project 2 : User Level Thread Library 15-410 Operating Systems September 19, 2003 1 Overview An important aspect of operating system design is organizing tasks that run concurrently and share memory. Concurrency
More informationCS 326: Operating Systems. Process Execution. Lecture 5
CS 326: Operating Systems Process Execution Lecture 5 Today s Schedule Process Creation Threads Limited Direct Execution Basic Scheduling 2/5/18 CS 326: Operating Systems 2 Today s Schedule Process Creation
More informationLecture 9: Midterm Review
Project 1 Due at Midnight Lecture 9: Midterm Review CSE 120: Principles of Operating Systems Alex C. Snoeren Midterm Everything we ve covered is fair game Readings, lectures, homework, and Nachos Yes,
More informationChapter 5: Process Synchronization. Operating System Concepts 9 th Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationCSE 153 Design of Operating Systems
CSE 153 Design of Operating Systems Winter 2018 Midterm Review Midterm in class on Monday Covers material through scheduling and deadlock Based upon lecture material and modules of the book indicated on
More informationA process. the stack
A process Processes Johan Montelius What is a process?... a computation KTH 2017 a program i.e. a sequence of operations a set of data structures a set of registers means to interact with other processes
More informationCS 105, Spring 2015 Ring Buffer
CS 105, Spring 2015 Ring Buffer March 10, 2015 1 Introduction A ring buffer, also called a circular buffer, is a common method of sharing information between a producer and a consumer. In class, we have
More informationSystèmes d Exploitation Avancés
Systèmes d Exploitation Avancés Instructor: Pablo Oliveira ISTY Instructor: Pablo Oliveira (ISTY) Systèmes d Exploitation Avancés 1 / 32 Review : Thread package API tid thread create (void (*fn) (void
More informationShared Memory Parallel Programming with Pthreads An overview
Shared Memory Parallel Programming with Pthreads An overview Part II Ing. Andrea Marongiu (a.marongiu@unibo.it) Includes slides from ECE459: Programming for Performance course at University of Waterloo
More information2 Threads vs. Processes
9 2 Threads vs. Processes A process includes an address space (defining all the code and data pages) a resource container (OS resource and accounting information) a thread of control, which defines where
More informationThis is a talk given by me to the Northwest C++ Users Group on May 19, 2010.
This is a talk given by me to the Northwest C++ Users Group on May 19, 2010. 1 I like this picture because it clearly shows what is private and what is shared. In the message-passing system, threads operate
More informationSynchronization 1. Synchronization
Synchronization 1 Synchronization key concepts critical sections, mutual exclusion, test-and-set, spinlocks, blocking and blocking locks, semaphores, condition variables, deadlocks reading Three Easy Pieces:
More informationCMSC 412 Project #3 Threads & Synchronization Due March 17 th, 2017, at 5:00pm
CMSC 412 Project #3 Threads & Synchronization Due March 17 th, 2017, at 5:00pm Overview User level threads. You will implement user level threads where each thread has it s own stack, but shares the program,
More information10/17/ Gribble, Lazowska, Levy, Zahorjan 2. 10/17/ Gribble, Lazowska, Levy, Zahorjan 4
Temporal relations CSE 451: Operating Systems Autumn 2010 Module 7 Synchronization Instructions executed by a single thread are totally ordered A < B < C < Absent synchronization, instructions executed
More informationCS 318 Principles of Operating Systems
CS 318 Principles of Operating Systems Fall 2017 Midterm Review Ryan Huang 10/12/17 CS 318 Midterm Review 2 Midterm October 17 th Tuesday 9:00-10:20 am at classroom Covers material before virtual memory
More informationIntroducing Shared-Memory Concurrency
Race Conditions and Atomic Blocks November 19, 2007 Why use concurrency? Communicating between threads Concurrency in Java/C Concurrency Computation where multiple things happen at the same time is inherently
More informationChapter 4: Threads. Operating System Concepts. Silberschatz, Galvin and Gagne
Chapter 4: Threads Silberschatz, Galvin and Gagne Chapter 4: Threads Overview Multithreading Models Thread Libraries Threading Issues Operating System Examples Linux Threads 4.2 Silberschatz, Galvin and
More informationNotes to Instructors Concerning the BLITZ Projects
Overview Notes to Instructors Concerning the BLITZ Projects Harry H. Porter III, Ph.D. Department of Computer Science Portland State University April 14, 2006 Revised: September 17, 2007 The BLITZ System
More informationProject 1 System Calls
Project 1 System Calls Introduction In this project, you will become familiar with: 1. Using the xv6 Makefile 2. Using conditional compilation. 3. The xv6 system call invocation path. 4. Implementing a
More informationOperating Systems. Thread Synchronization Primitives. Thomas Ropars.
1 Operating Systems Thread Synchronization Primitives Thomas Ropars thomas.ropars@univ-grenoble-alpes.fr 2017 2 Agenda Week 42/43: Synchronization primitives Week 44: Vacation Week 45: Synchronization
More informationCSE 451 Midterm 1. Name:
CSE 451 Midterm 1 Name: 1. [2 points] Imagine that a new CPU were built that contained multiple, complete sets of registers each set contains a PC plus all the other registers available to user programs.
More informationPage 1. Goals for Today" Atomic Read-Modify-Write instructions" Examples of Read-Modify-Write "
Goals for Today" CS162 Operating Systems and Systems Programming Lecture 5 Semaphores, Conditional Variables" Atomic instruction sequence Continue with Synchronization Abstractions Semaphores, Monitors
More informationMULTITHREADING AND SYNCHRONIZATION. CS124 Operating Systems Fall , Lecture 10
MULTITHREADING AND SYNCHRONIZATION CS124 Operating Systems Fall 2017-2018, Lecture 10 2 Critical Sections Race conditions can be avoided by preventing multiple control paths from accessing shared state
More informationSemaphore. Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }
Semaphore Semaphore S integer variable Two standard operations modify S: wait() and signal() Originally called P() and V() Can only be accessed via two indivisible (atomic) operations wait (S) { while
More informationPebbles Kernel Specification September 26, 2004
15-410, Operating System Design & Implementation Pebbles Kernel Specification September 26, 2004 Contents 1 Introduction 2 1.1 Overview...................................... 2 2 User Execution Environment
More informationCondition Variables & Semaphores
Condition Variables & Semaphores Nima Honarmand (Based on slides by Prof. Andrea Arpaci-Dusseau) Review: Concurrency Objectives Mutual Exclusion A & B don t run at the same time Solved using locks Ordering
More informationHigh-level Synchronization
Recap of Last Class High-level Synchronization CS 256/456 Dept. of Computer Science, University of Rochester Concurrent access to shared data may result in data inconsistency race condition. The Critical-Section
More informationTHREADS & CONCURRENCY
27/04/2018 Sorry for the delay in getting slides for today 2 Another reason for the delay: Yesterday: 63 posts on the course Piazza yesterday. A7: If you received 100 for correctness (perhaps minus a late
More information4. The Abstraction: The Process
4. The Abstraction: The Process Operating System: Three Easy Pieces AOS@UC 1 How to provide the illusion of many CPUs? p CPU virtualizing w The OS can promote the illusion that many virtual CPUs exist.
More informationPage 1. Goals for Today. Atomic Read-Modify-Write instructions. Examples of Read-Modify-Write
Goals for Today CS162 Operating Systems and Systems Programming Lecture 5 Atomic instruction sequence Continue with Synchronization Abstractions Semaphores, Monitors and condition variables Semaphores,
More informationCPS 310 first midterm exam, 10/6/2014
CPS 310 first midterm exam, 10/6/2014 Your name please: Part 1. More fun with fork and exec* What is the output generated by this program? Please assume that each executed print statement completes, e.g.,
More informationProcesses and Threads
1 Programs and Processes 1.1 What is a program? At its simplest, a program is a collection of instructions that are to be executed by the CPU. The program begins life as source code and is, most commonly,
More information