Scheduler With Signals-Lab06 Manual

Lab06 Manual In the last project, we built a OS process manager by using semaphore. The PM can only assign a certain number of PID to processes (workers) at one time. In this project, we are to simulate a time-sharing system by using signals and timers. The data structure and worker thread have been well implemented with semaphore. You will focus on implementing the scheduling algorithm (Round Robin). Since we can not change actual “time slices” in OS we use interval timers to model it. The scheduler is installed with an interval timer. The timer starts ticking when the scheduler picks a thread to use the CPU which in turn signals the thread when its time slice is finished thus allowing the scheduler to pick another thread and so on. When a thread has completely finished its work it leaves the scheduler to allow a waiting thread to enter. Please note that in this project, only the timer and scheduler send signals. The threads passively handle the signals without signaling back to the scheduler. The goal of this project is to help you understand (1) how signals and timers work, and (2) how to evaluate the performance of your program. (3) understand how the POSIX:TMR interval timer works. You will first implement the time-sharing system using timers and signals. Then, you will evaluate the overall performance of your program by keeping track of how long each thread is idle, running, etc. The program takes a number of arguments. Arg1 determines the number of jobs (threads in our implementation) created; arg2 specifies the queue size of the scheduler. Arg3 through argN gives the duration (the required time slices to complete a job) of each job. Hence if we create 2 jobs, we should supply arg3 and arg4 for the required duration. You can assume that the autograder will always supply the correct number of arguments and hence you do not have to detect invalid input. The program will use these four signals: SIGALRM: sent by the timer to the scheduler, to indicate another time quantum has passed. SIGUSR1: sent by the scheduler to a worker, to tell it to suspend. SIGUSR2: sent by the scheduler to a suspended worker, to tell it to resume. SIGTERM: sent by the scheduler to a worker, to tell it to cancel. All code that does this will be in scheduler.c. Part I: Modify the scheduler code ———————————————– The start code uses the scheduler thread to setup the timer and handle the scheduling for the system. The scheduler handles the SIGALRM events that come from the timer, and sends out signals to the worker threads.

The starting code has initialized the scheduler with a POSIX:TMR interval timer in init_sched_queue() function in scheduler.c. CLOCK_REALTIME is used in timer_create(). The timer will be stored in the global variable “timer”, which will be started in scheduler_run(). sigaction() is used in setup_sig_handlers() to install signal handlers for SIGALRM, SIGUSR1, and SIGTERM. SIGALRM triggers timer_handler(), SIGUSR1 triggers suspend_thread(), and SIGTERM triggers cancel_thread(). Notice no handler is installed for SIGUSR2; this signal will be handled differently, in worker.c which handles the signals from the scheduler. start_worker() in worker.c immediately suspends the thread, waiting for a resume signal from the scheduler ((1) block SIGUSR2 and SIGALRM, and (2) unblock SIGUSR1 and SIGTERM). sigwait() is used in suspend_thread() to force the thread to suspend itself based on the SIGUSR1 signal and wait for a resume signal (SIGUSR2). Step 1. (5 pt) In the scheduler_run() function, start the timer. Use timer_settime(). The time quantum (1 second) is given in scheduler.h. The timer should go off repeatedly at regular intervals defined by the timer quantum. In Round-Robin, whenever the timer goes off, the scheduler suspends the currently running thread, and tells the next thread to resume its operations using signals. These steps are listed in timer_handler(), which is called every time the timer goes off. In this implementation, the timer handler makes use of suspend_worker() and resume_worker() to accomplush these steps. Step 2. (5 pt) Complete the suspend_worker() function. First, update the info->quanta value. This is the number of quanta that remain for this thread to execute. It is initialized to the value passed on the command line, and decreases as the thread executes. If there is any more work for this worker to do, send it a signal to suspend, and update the scheduler queue. Otherwise, cancel the thread. Step 3. (5 pt) Complete the cancel_worker() function by sending the appropriate signal to the thread, telling it to kill itself. Step 4. (5 pt) Complete the resume_worker() function by sending the appropriate signal to the thread, telling it to resume execution.

Part II: Modify the evaluation code ————————————————– This program keeps track of run time, and wait time. Each thread saves these two values regarding its own execution in its thread_info_t. Tracking these values requires also knowing the last time the thread suspended or resumed. Therefore, these two values are also kept in thread_info_t. See scheduler.h. You will implement the functions that calculate run time and wait time. When the program is done, it will collect all these values, and print out the total and average wait time and run time. For your convenience, you are given a function time_difference() to compute the difference between two times in microseconds. Step 5. (5 pt) Modify create_workers() to initialize the various time variables. Step 6. (5 pt) Implement update_run_time(). This is called by suspend_worker(). Step 7. (5 pt) Implement update_wait_time(). This is called by resume_worker(). Step 8. (15 pt) Test your code with 4 worker threads with queue size 2. You can set quanta yourself. Your result should show the statistics at the last lines. Output: Here is an example of program output, once the program is complete:

Tips: 1. Make file is provided. 2. You will use these functions (not limited to): pthread_kill timer_settime clock_gettime Submission Instruction:

You can run your code as scheduler.c but change the name of the file to yourCSUNID.c. The PDF file comprising screenshot of your output and tracking report needs to be named following this format, YourCSUNID_YourLastName.pdf Both files need to be submitted here in Canvas. Submission failed to meet the submission requirement will not be graded. Grade may be forfeited.