Goals

There are two main goals for this project:

• To familiarize you with the dlxos system—how it works, how to use it, and how to compile code for it.
• To modify the dlxos scheduler to be more flexible. You must implement
  • A two-level round-robin scheduler.
  • A priority-based scheduler
  • (extra credit) A scheduler that dynamically adjusts priorities to be more fair to processes that wait frequently.
  • (extra credit) A lottery scheduler.

You should also read over the general project information page before you start this project. In it, you'll find valuable information about the DLXOS system as well as general guidelines and hints for projects in this class.

Details

In this project, you will modify the scheduler for DLXOS. This should only involve modifying code in process.c and process.h, though you may want to look at other modules to see how they fit together (you may, of course, modify code elsewhere if you wish).

Choosing a scheduling algorithm

You should pass an argument to the operating system (-S n) that determines the scheduling algorithm (see the code in main() for hints on how to pass arguments to the operating system at startup). The algorithm may not change during operating system execution. The algorithms are:

• 0: default (original) scheduling: round robin with no modifications
• 1: two round robin queues, one for short jobs and one for long jobs
• 2: priority-based scheduling
• 3: (extra credit) dynamic scheduling
• 4: (extra credit) lottery scheduling

Dual round robin queues

The first algorithm you need to implement uses two round robin queues. Processes are placed into the first queue when they are created, and move to the second queue after they have had five quanta (i.e., they have been scheduled five times). The scheduler runs all of the processes in the first queue once and then runs a single process from the second queue. This can be implemented in several ways; one possibility is to include a "pseudo-process" in the first queue that, when at the front of the queue, causes a process from the second queue to be run.

Assume the following processes are in the two queues:

Queue 1: P1 P2 P3
Queue 2: P4 P5 P6 P7

The scheduler would run processes in this order:

P1 P2 P3 P4 P1 P2 P3 P5 P1 P2 P3 P6 ...

This allows long-running processes to make (slow) progress, but gives high priority to short-running processes.

Priority-based scheduling

For this algorithm, the scheduler always selects the highest-priority process in the ready queue. A process's priority is set with ProcessSetPriority (int processID, int n), which you will have to write. Higher values of n mean a higher priority. If there are several processes with a particular priority, they are selected round-robin (they should receive approximately equal slices of CPU time). You may implement this algorithm using a single queue, scanning down it for the highest-priority process, or you may use multiple queues. It is likely, however, that it will be easier to implement using a single queue.

Note that a process's priority may change during execution if ProcessSetPriority() is called.

Extra credit

You may receive extra credit for implementing dynamic priority assignment (5 points) and/or lottery scheduling (15 points). However, you can only receive extra credit if the required portion of the project is working. In other words, do the required assignment first. Also, your extra code shouldn't break your required code; we strongly suggest that you use a revision control system (such as RCS) to make sure you keep a working version of your code.

For dynamic priority assignment, you should modify priority scheduling to multiply a process's priority by 0.90 each time it receives a full quantum, and increase its priority by 1 each time it blocks without exhausting its quantum. A process's priority should never drop below 1, and should never exceed its original (desired) priority.

For lottery scheduling, you should assign tickets using ProcessSetPriority(), where n corresponds to the number of tickets given to the process. Each time the scheduler is called, it should randomly select a ticket (by number) and run the process holding that ticket. Clearly, the random number must be between 0 and nTickets-1, where nTickets is the sum of all the outstanding tickets. You may use the random() call to generate random numbers and the srandom() call to initialize the random number generator (these calls function the same way they do in Unix).

Hints

• START EARLY! You should start with your design, and check it over with the professor, TA, or tutor.
• The code you'll need to modify is in process.c and process.h. In particular, you'll be making lots of changes to ProcessSchedule().
• START EARLY!
• You will almost certainly have to modify the PCB structure (process control block).
• START EARLY!
• Test your changes. You can create processes in sysproc.c—see the code for examples of how to do this. You may want to try the following:
  • Create long and short running processes. Have each short running process create another short running process right before it exits.
  • Create processes of different priorities and make sure they run properly.
  • Modify a process's priority while it's running.
• Use RCS to keep multiple revisions of your files. RCS is very space-efficient, and allows you to keep multiple "coherent" versions of your source code and other files (such as Makefiles).
• Did we mention that you should START EARLY!

Project groups

The first project must be done individually; however, later projects (numbers 2-4) may be done in pairs. It's vital that every student in the class get familiar with how to use the DLXOS system; the best way to do that is to do the first project yourself. For the second, third, and fourth projects, you may pick a partner and work together on the project.

Working on the project

We assume that you are already familiar with makefiles and debugging from earlier classes such as CMPS 101. If not, this will be a considerably more difficult project because you will have to learn to use these tools as well.

This project doesn't require a lot of coding (probably less than 100 lines), but does require that you understand what's going on inside the operating system and how to use the DLX simulator and compilation tools. You're encouraged to go to the class discussion section or visit the professor's or TA's office hours to get help if you need it.

You should do your design first, before writing your code. To do this, compile and run the operating system, inserting debugging print statements if you like. It may be more "fun" to just start coding without a design, but it'll also result in spending more time than you need to on the project.

IMPORTANT: As with all of the projects this quarter, the key to success is starting early. You can always take a break if you finish early, but it's impossible to complete a 20 hour project in the remaining 12 hours before it's due....

What to hand in

As with other projects, you'll need to hand in your design documentation and your code, both of which must be handed in using the online submission system. More details on what to hand in can be found on the general project information page.

Grading

The TA will likely test your code by creating processes and seeing how the scheduler handles them. Thus, please use the function call names and parameters listed in the assignment. If you provide information about how you tested your code (and whether it was successful), the TA may be able to give you "credit" for things that worked for you even if she finds things that don't work with her tests.