OPERATING SYSTEMS, ASSIGNMENT 2 KERNEL THREADS IN XV6, SYNCHRONIZATION

Transcription

1 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 shell, and traverse to the desired working directory. Execute the following command (in a single line): svn checkout assignment2 This will create a new folder called assignment2 which will contain all project files. Kernel level threads (KLT) are implemented and managed by the kernel. One can look at kernel threads as processes who share some of their attributes as peer threads in the same process. One key characteristic of threads is that all threads of the same process share the same virtual memory space. As such, a simple way to add threads to XV6's implantation is to use code much similar to that of the fork system call, which creates another process. To achieve a thread-like behavior we will have the newly created "process" share the same virtual memory space of the "parent process". By doing so, both "processes" share the same virtual memory space, and so may essentially be considered as two threads. You will need to mark the new "process" internally so the kernel can tell whether it is a process or one of our newly created "threads". Each thread should keep the PID of the process within which it is running. Task 1: Kernel Threads In this part of the assignment you will add system calls that will allow programs to create kernel threads. Implement the following new system calls: int thread_create( void*(*start_func)(), void* stack, uint stack_size ); Calling thread_create will create a new thread within the context of the calling process. The newly created thread state will be runnable. The caller to thread_create must allocate a stack for the new thread to use. start_func is a pointer to the function 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. int thread_getid(); Upon success, this function returns the caller thread's id. In case of error, a non-positive error identifier is returned. The thread s ID should be unique for each of the threads in the same process.

2 int thread_getprocid(); Upon success, this function returns the process ID. When a process (say PID=7) first starts running, we say it has a single main thread, and the thread_getprocid simply returns the process pid (7). If that process later creates new threads, those threads would also return its pid (7) since they are all threads of the same simulated process. Notice that the existing system call Sys_getpid that is already implemented should not be changed, as it is used for other purposes which we would not want to harm. int thread_join(int thread_id, void** ret_val) This function suspends the execution of the calling thread until the thread identified by thread_id terminates. thread_id is the identifier of the thread that needs to be waited for. If thread thread_id already finished execution, the call to this function should return immediately after setting ret_val. ret_val is the return value of thread_id 's function (as described in thread_exit). Calling thread_join on a thread thread_id on which another thread is already waiting for should fail and return -2. On all other errors this function should return -1. On success, should return 0 and set the ret_val. void thread_exit(void * ret_val); This function terminates the execution of the calling thread. If called by the main thread while other threads exist within the same process, it shouldn t terminate the whole process. ret_val is the return value of the thread's function, and should be stored in case another thread calls thread_join on the exiting thread. Task 2: Synchronization primitives In this task you will implement two synchronization primitives: Binary Semaphores and Counting Semaphores. Task 2.1: Binary Semaphores In this part of the assignment you will add system calls that allow users to create and use binary semaphores. Before you start your implementation, you should 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 cores while they change the status of processes. Your task is to implement binary semaphores as a kernel service to users, via system calls. The locking and releasing can be based on the implementation of spinlocks (remember spinlocks are made for the kernel's internal specific use). Notice spinlocks are NOT the same as binary semaphores, for example starvation can happen with spinlocks but not with semaphores due to the queue of waiting threads that the semaphore maintains. The semantics of binary semaphores were described in class and include the two operations described below.

3 Add the following system calls to the XV6 kernel: int binary_semaphore_create(int initial_value) This function creates and initializes a new binary semaphore and returns the identifier (binary_ semaphore _ID) of the newly created semaphore. The semaphore is initialized to initial_value. The functions binary_ semaphore _down and binary_ semaphore _up work as learned in class, and return 0 if successful and -1 if an error occurs. int binary_ semaphore _down(int binary_ semaphore _ID) int binary_ semaphore _up(int binary_ semaphore _ID) Note: you will need to assign and manage the IDs of semaphores inside the kernel. Task 2.2: Counting Semaphores Implement counting semaphores. Your implementation should rely on the system calls you added in the previous task. Implementing counting semaphores using binary semaphores was taught in class. Your implementation should be done outside of the kernel, as a user-space program called semaphore.c and semaphore.h (not as system calls). Implement the following functions: struct semaphore* semaphore_create(int initial_ semaphore_value); void semaphore_down(struct semaphore* sem ); void semaphore_up(struct semaphore* sem ); You may want to write some code now to fully test your semaphores and make sure they work flawlessly. Task 2.3: Synchronized Bounded Buffer Implement a synchronized bounded buffer using semaphores. Implement this via a user space program, boundedbuffer.c and boundedbuffer.h. The buffer has a finite capacity defined at creation and behaves as expected (trying to enter an item when the buffer is full causes the thread to wait until there are free slots in the buffer. Trying to remove elements from an empty buffer causes the thread to wait as well). Implement the following functions: struct BB* BB_create(int max_capacity); This function creates a new bounded buffer, with a max_capacity capacity. void BB_put(struct BB* bb, void* element); This function will try to put the element received in the buffer. If there is no room for the element, it will wait until there is a free slot.

4 void* BB_pop(struct BB* bb); This function should return a single element from the buffer. If the buffer is empty it will cause the thread to wait until there is an element to remove. You might want to consider adding some auxiliary function to support your bounded buffer. Part 3: Synchronization Problem Task 3.1: Thread test Write a program called threadtest which receives a positive integer argument n from the command line. The program creates a single binary semaphore called the lock, and n threads and runs them. Each thread runs in an infinite loop, printing a line three times (see below). Each thread must acquire the lock just before printing, and must release it immediately after printing the line three times. After releasing the lock the thread performs sleep(1). The line each thread should print is: Process < thread_getprocid()> Thread < thread_getid()> is running. Task 3.2: Synchronization Problem In this part you will write a Consumer-Producer application that will create new threads and put them to test. Your application will receive its parameters from a configuration file (described below). All printing should go to a file named Synch_problem_log.txt. Problem description The Bienstein is a student bar in Beer-Sheva that just opened right across the street from the university. It opened right at the beginning of finals period, so all the students, especially the ones that don t want to study, want to try it out. A. Data Structures: There are five data structures you need to use. 1. The first data structure is a counting semaphore, called bouncer, used to allow students to enter the Bienstein. The bouncer manages the number of students that can be at the bar at once. This counting semaphore s initial value will be M, the maximum number of students that can be at the bar at once. The bouncer must support the following synchronized actions:

5 void enter_bar() used to allow students to enter the bar, and thus is called by the students. If the bar is full (the semaphore s value is 0), the student should wait until another student leaves the bar and frees up space. void leave_bar() used to allow students to leave the bar once they are drunk, and thus is called by the students. When a student leaves the bar, he frees up a place for another student to enter. 2. The second data structure is a bounded buffer, called ABB, used to hold the students actions. This bounded buffer has A slots, is produced by the students, and consumed by the bartenders. It will use the Action struct that you will define, which is composed of: type, cup*, and tid (the thread's id). The type of the Action can be a drink order, or the returning of a cup (type=1 means a drink order, type=2 means the returning of a cup). ABB must support the following synchronized actions: void place_action(action* action) This function is called by a student whenever he wants to perform an action - place an order for a drink from the bar or return a dirty cup. The action is placed at the end of the buffer. Action* get_action() This function is called by a bartender whenever one is free to deal with students actions. The Action located at the beginning of the buffer is returned and removed. If there are no actions, the bartender will wait until more actions arrive. 3. The third data structure is a bounded buffer, called DrinkBB, used to hold the ready drinks. This bounded buffer has A slots, is produced by the bartenders, and consumed by the students. It will use the Cup struct that you should define as you see fit. DrinkBB must support the following synchronized actions: void serve_drink(cup*) This function is called by the bartender whenever he finishes to make a drink (ordered by a student). The cup the drink is made in is placed in the DrinkBB. Cup* get_drink() This function is called by a student after he places an order for a drink, while he waits for his order to be made. If there is a drink ready in the buffer, he will take it (denoted by the cup the drink was made in). If not, he will wait until a drink becomes available.

6 4. The fourth data structure is a bounded buffer, called CBB, used to hold the clean cups for the drinks. This bounded buffer has C slots, is produced by the cup boy, and is consumed by the bartenders. It will use the Cup struct. CBB must support the following synchronized actions: Cup* get_clean_cup() This function is called by a bartender whenever he wishes to make a drink and needs a clean cup for it. If there are no clean cups left, the bartender should wait until the cup boy returns with clean cups. void add_clean_cup(cup* cup) This function is called by the cup boy when he wishes to add a clean cup he just washed. 5. The fifth data structure is a bounded buffer, called DBB, used to hold the dirty cups. This bounded buffer has C slots, is produced by the students, and is consumed by the cup boy. DBB must support the following synchronized actions: void return_cup(cup* cup) This function is called by a bartender whenever a student finished to drink his drink and wishes to return the cup used (i.e when the type of the action the bartender received from ABB is 2 - returning a dirty cup). If at least 60% of the cups are dirty, the cup boy will be notified. Cup* wash_dirty() This function will be called by the cup boy when he wishes to get a dirty cup to clean. B. The Students There are S students in the simulation, where each is a thread. The students actions can be abstracted as follows: 1. Call enter_bar. 2. Repeat k (described below) times: a. Call place_action with a drink order as the action (in the struct action: type = 1, cup=null). b. Call get_drink. c. Print (to a file) Student <thread_id> is having his <drink_number> drink, with cup <cup_number> (as returned from get_drink). d. sleep(1). e. Call place_action with returning a cup as the action (in the struct action: type = 2, and cup=cup received from get_drink).

7 3. print (to a file) Student <thread_id> is drunk, and trying to go home. 4. Call leave_bar. Where k equals thread_id % 5. C. The Bartender There are B bartenders, where each is a thread. The bartenders actions will be in an infinite loop composed of the following abstracted actions: 1. Call get_action. 2. If the action is a drink order: a. Call get_clean_cup. b. Print (to a file) Bartender <thread_id> is making drink with cup #<cup_id>. c. Call serve_drink. 3. If the action is returning a cup: a. Call return_cup. b. Print (to a file) Bartender <thread_id> returned cup #<cup_id>. D. The Cup Boy There is a single cup boy, who is a thread. The cup boy sleeps until it is notified that the DBB is 60% full the students returned 60% of the cups (that are now dirty). When it wakes up its actions can be abstracted as follows: 1. Repeat n times: a. Call wash_dirty. b. sleep(1). c. Call add_clean_cup. d. Print(to a file) Cup boy added clean cup #<cup_number>. Where n is the amount of dirty cups when the cup boy starts washing them (which means that if new dirty cups are added before the cup boy finishes washing them, they will not be added to n and he will not wash them now). E. Configuration File You need to add a configuration file to xv6 and name it con.conf (remember to make the necessary changes in the Makefile). Your application must be able to read parameters from the configuration file and start a simulation according to it. The configuration file has the following parameters: M = value1 A = value2 C = value3 S = value4

8 B = value5 You can assume that the number of cups is at least twice the number of students allowed to enter the bar at once. That is, 2M < C. Note: the simulation ends once the last student leaves the Bienstein. Make sure that all threads have exited gracefully, and that all memory allocated has been freed. F. The Simulation The simulation should be started with the CBB full of C clean cups, the DBB is empty of dirty cups, and there are no students in the bar. When the simulation starts all the students try to enter the bar. Then the simulation continues as described above. Your implementation should not use busy wait, but use the data structures defined above. Using busy wait will reduce your grade. Submission guidelines Assignment due date: 9/5/2013 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 patch (i.e. a file which patches the original xv6 and applies all your changes). You may use the following instructions to guide you through the process: Back-up your work before proceeding! Before creating the patch review the change list and make sure it contains all the changes that you applied and noting more. Modified files are automatically detected by svn but new files should be added explicitly with the svn add command: > svn add <filename> In case you need to revert to a previous version: > svn revert <filename> At this point you may examine the differences (the patch): > svn diff Alternatively, if you have a diff utility such as kompare: > svn diff kompare o -

9 Once you are ready to create a patch simply make sure the output is redirected to the patch file: > svn diff > ID1_ID2.patch 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. Enjoy!