Project VI: Disk Scheduling

  • Frequently Asked Questions
  • The goals of this project are:
  • to learn the code mechanics of writing an operating system request scheduler.
  • to demonstrate mastery in solving concurrency problems.
  • to gain further experience in quantitative system evaluation.
  • to gain further experience in writing short technical reports.
  • This project may be completed in either pairs or singletons. Submit your project to only one dropbox, and clearly indicate in your lab report the members of your group. Both members of the group will receive the same grade.

    Project Overview

    In this project, you will build a scheduling system for a hard disk. We will provide you with a virtual disk object that has some inconvenient features, and a simple program that makes requests from that disk. Your scheduler will sit between the two and provide both synchronization and improved performance via scheduling.

    Once your system is working correctly, you will evaluate the performance of several disk scheduling algorithms with a varying number of programs running. You will write a short lab report that explains the experiments, describes your results, and draws conclusions about the behavior of each algorithm.

    Getting Started

    Begin by downloading the source code and building it. Look through main.c and notice that the program creates a disk_scheduler object, multiple threads that run program_run, and then one thread that runs disk_scheduler_run. The run is complete when all of the threads running program_run have completed.

    The disk object in this project has the same interface as the last project, but the implementation has two of the inconvenient features of a real disk drive:

  • The disk can only support a single read or write at a time. If multiple threads attempt to call disk_read or disk_write, the program will "crash" with a loud error message.
  • The disk takes time to respond to each request: each block is about a millisecond apart. So, reading block 0, then block 10, then block 20 will take 20 milliseconds. But, reading block 0, then 20, then 10 will take 30 milliseconds total. (This is slower than a real disk, which makes it easier to observe the effects of scheduling.)
  • If we simply allowed each program to call disk_read and disk_write directly, then chaos would result. Instead, each program will call disk_scheduler_read and disk_scheduler_write, which will work in concert with disk_scheduler_run to address the two problems of the disk.

    As provided, the scheduler doesn't do any work at all, except to pass reads and writes directly on to the disk. It works correctly with one thread:

    % ./disksched 2 10 fifo
    main: starting program threads
    main: starting disk scheduler thread
    read block 9 starting
    read block 9 done
    write block 4 starting
    write block 4 done
    But it crashes with more than one:
    % ./disksched 2 10 fifo
    main: starting program threads
    main: starting disk scheduler thread
    read block 9 starting
    write block 4 starting
    DISK CRASH: two threads tried to use the disk at once!
    Your job is to implement the disk scheduler. The basic idea is that disk_scheduler_read and disk_scheduler_write should add a request object to an appropriate data structure. disk_scheduler_run should wait for request objects, and then pick the most appropriate one based on the desired scheduling algorithm, satisfy the request, and then wake up the waiting program.

    Essential Requirements

    Your program must be invoked as follows:
    % ./disksched <nthreads> <nblocks> fifo|sstf|scan
    nthreads is the number of threads that will access the disk, nblocks is the number of blocks in the virtual disk, and fifo, sstf, and scan indicate the scheduling algorithm to be used, as discussed in class.

    You may only modify the file disk_scheduler.c.

    A complete and correct program will run to completion with only the three lines of output from main. You may certainly add some printfs while testing and debugging your program, but the final version should not have any extraneous output. (Extra output will throw off the timing of your program.)

    You will also turn in a lab report that has the following elements:

  • In your own words, briefly explain the purpose of the experiments and the experimental setup. Be sure to clearly state on which machine you ran the experiments, and exactly what your command line arguments were, so that we can reproduce your work in case of any confusion.
  • Measure and graph the execution time of disksched for each scheduling algorithm on disks of 10, 50, and 100 blocks for 1 to 10 threads executing at once. Spend some time to make sure that your graphs are nicely laid out, correctly labelled, and easy to read, as discussed in class. Do not use colored backgrounds. You may connect data points with straight lines, but not with splines or curves.
  • Explain the nature of the results. If one algorithm performs better than another under certain conditions, then point that out, explain the conditions, and explain why it performs better.
  • Grading

    Your grade on this assignment will be based on the following:
  • Correct implementation of disk scheduling including both synchronization for safety and selection of the proper request to proceed next. (50%)
  • A lab report which is clearly written using correct English, contains an appropriate description of your experiments, contains correct results that are clearly presented, and draws appropriate conclusions. (30%)
  • Thorough attention to and handling of all possible error conditions, including user error. (10%)
  • Good coding style, including clear formatting, sensible variable names, and useful comments. (10%)
  • Turning In

    Turn in all of your source code and a Makefile that builds disksched when the user types make. Turn in a lab report named report.doc or report.pdf that clearly indicates the members of your group. Please do not turn in executables or other large files. All files should be copied to your dropbox directory here:
    This assignment is due at 5PM on Thursday, April 30th. Late assignments will not be accepted. Your program will be compiled and graded on the Linux machines in the Fitzpatrick computer lab. Therefore, you should do your development work either sitting in that lab, or using ssh to connect to the machines remotely. The TAs will hold office hours in the lab, and will be happy to help you with those machines.

    If you insist on doing the homework on your personal computer or laptop, then you are on your own. Please do not ask the TAs to fiddle around with your personal computers. Leave extra time to ensure that your program works correctly when transferred to the Fitzpatrick machines.