Part 0, 0 points: I have written two classes that you'll need to use in this project: Job.java and CPU.java. You'll probably want to get comfortable with Job's public getter methods so you can call them with your scheduler. DO NOT SUBMIT these files with your final code.

Part 1, 0 points: Create a new Java file, MyScheduler.java. Include a file header with your names.

Part 2, 0 points: If you're not using a super fancy IDE and have to import packages yourself, you will almost certainly want both java.util.* and java.util.concurrent.*. You'll at least have to have java.util.concurrent.LinkedBlockingQueue.

Part 3, 0 points: Your MyScheduler class will be tested in the following way:

• The constructor will be called, and the type of the test (e.g. what property will be measured) will be given as one of the parameters.
• You get to create the LinkedBlockingQueues that will be used to feed Jobs into and out of the scheduler. (Your code will take in jobs on the incoming queue and then put them in the outgoing queue in whatever order it--your code--decides.)
• Then the simulation will generate a bunch of jobs right off the bat to give to the scheduler and get things moving.
• In the second phase of the simulation, it will feed jobs to the scheduler at (kinda) random intervals.
• After all jobs have been processed, the tester will spit out a bunch of stats about the test, measure the indicated property, then move on to the next test.
• After all tests have been run, the code will show the different metrics that were measured and show how many points was earned for each part.

Part 4, 0 points: Add the constructor,

public MyScheduler(int numJobs, String property) {

• "avg wait": the average waiting time will be measured
• "max wait": the maximum waiting time will be measured
• "combined": the max wait time plus two times the average wait time will be measured
• "deadlines": the number of jobs that finished by their deadline

Part 5, 0 points: Add a method, getOutgoingQueue that takes no parameters and returns a BlockingQueue of Jobs:

public LinkedBlockingQueue<Job> getOutgoingQueue() {

Part 6, 0 points: Add a method, getIncomingQueue that takes no parameters and returns a LinkedBlockingQueue of Jobs. This is the queue where your scheduler will receive the jobs as they are created. Again, I imagine you'll want to create this in the constructor. The tester code needs this because it needs to know how to send new jobs to your scheduler.

Part 7, 25 points: Next you want to implement the run method:

public void run() {

• You will take jobs from the incoming queue (and probably store them), and
• You will put jobs on the outgoing queue in the order of your choosing.

Part 8, 0 points: To test your code, you should run it with my tester: SchedulerTester.java. I will use this code to test your project when I grade it. Just like in prior projects, you'll want to run it with assertions enabled. If the tests are taking too long when you're first setting things up, you can also adjust the number of jobs that are created:

$ javac *.java
$ java -ea SchedulerTester
...
$ java -ea SchedulerTester 50
... runs the tests with 50 jobs...

Part 9, 50 points: I recommend working on the max wait setting first. (What scheduling algorithm is best for this?) Implement that algorithm and run the tests and try to score the maximum number of points. The testing code has brackets, each one worth a different number of points. The lower time intervals are worth more points. When you have the correct algorithm implemented, the tester should run pretty consistently with full points.

Part 10, 50 points: The avg wait setting is probably the second-easiest version to get. The point brackets work similarly, though they are using much smaller values. Again, for this one, when you have the correct algorithm implemented, the tester should run pretty consistently with full points.

Part 11, 50 points: I recommend doing the combined version next In this one, you'll need to find a balance between the maximum and average wait times. I tried out a bunch of different formulas and found one that had pretty good performance. This, however, is not nearly as consistent as the prior two. My version gets full points a bit more than 50% of the time. If you can reach close to that frequency, I'll be willing to run your code multiple times. It will be very helpful for you to let me know what score you're expecting.

Part 12, 50 points: The deadlines setting is easily the hardest version. For me, this required some extra programming. (Remember that you do have to run all jobs to completion.) My version gets full points well above 50% of the time, but my utility is only in the mid-80%s, and I haven't found a fix for that. Again, I'm very willing to run your code multiple times when I'm grading. It will be helpful for me to know what to expect.

Part 13, 0 points: This is a hard project. I am expecting that groups will have to meet with me to get some direction. Please come by my office and ask questions! Communicate early and often! You're going to want to strive for consistency, so test your code multiple times in each of the categories. Do not expect that it will always run perfectly. Don't treat your first trial run as the way it will always play out! I am willing to run your code multiple times and take the best score (overall, not for each part) but I'm not willing to run it incessantly because you had a good run once in a blue moon. If you get stuck and don't know how to improve your code, please come visit me!

Submitting your Project: Upload your code to canvas. You should definitely upload your MyScheduler.java file, as well as any other files you used. If you get it up before the deadline and send me a message, I can run a test on my own computer. (There is no limit to the amount of times you can ask me to do this. The only barrier is how much time I actually have, so submit early and often.) Make sure the names of all group members are in the code header.