OS Module - Modification

[mtfuller]

Modify the OS Module to do the following:

Loader

• File the Disk with Pages from each Process. No two processes can share a page.

  Long Term Scheduler

• Allocate four frames per process and update each process’ corresponding Page Table

  Short Term Scheduler

• Modify STS to use pcbQueue so that we preserve order

  Kernel

• Create Page Fault Queue
• Create I/O Queue

  OS Driver

• Revisit the while loop in the OS Driver

[ghost]

Just to update - I'm sorry for the delay. I've pushed my latest updates to my particular branch. On the "Modifications" document on the shared Google Drive, I've crossed out the items I've completed. I wasn't able to test anything, because the copies of the CPU module items I have don't jive with the new paged memory items.

Here's what I've completed:

• the Loader writes each job to the paged Disk class
• the PCB's 3 buffers are all now collections of pages
• the PageTable() class is simply two arrays - one to hold RAM page numbers, and one to hold the corresponding boolean valid/invalid bits. Each PCB has its own PageTable. Getters & setters are available.
• the Long Term Scheduler writes each job's first 4 frames to RAM and updates each PCB's PageTable

I did change two items of William's Disk() - I know we talked about this the other day at school, but when writing to Disk, it was easier for me within the Loader class to write to Disk instruction by instruction, instead of passing in a written Page. So I commented out his method to write to Disk and wrote a new method that allowed me to do that. If this causes trouble for any other part of the program, let me know and I will figure out how to write to Disk page by page.

I also added a "nextFreePage" pointer to Disk, which does what it sounds like - points the Loader to the next clean page to write on. This was the only way I could figure out how to make sure no two jobs share a page in Disk.

I still have the STS, Kernel, and Page Manager to complete, and I hope to have those done by Sunday afternoon at the latest. I will be available online all week, except for Tuesday and Friday, when I'll be traveling to/from Memphis. Otherwise, I can meet up in person next weekend either day or for a Google hangout any day at all.

Let me know if anyone runs into trouble with my code - like I said, nothing's been tested, so fingers crossed! :)

[ghost]

I'm able to test my classes now. I will update my branch's README as I progress.

[mtfuller]

Awesome! Sounds great.

[ghost]

Just to clarify - I know we've covered this process many times, but I want to make sure I understand, starting from the ShortTermScheduler.

• The STS hands off a job from the pcbQueue to a CPU
• The CPU tries to read the instructions, and if there are lines that haven't been written to RAM (invalid bit), the CPU just tells the STS "Give me another job because I can't do anything with this."
• the STS hands off the next job from the pcbQueue to a CPU
• Meanwhile, the jobs that are in the pageFault and IO queues are having their next instructions written to RAM.
• When a job's pages have been updated in RAM, they're popped off whichever queue they're in and their place in the pcbQueue is updated, so the overall sorted order is preserved.

Is that correct? If so, here are some questions:

• How can I determine the interrupt type (page fault or I/O), or will the CPU move the job to the appropriate queue in the Kernel? (There are methods to do this.)
• Who actually writes the job's instructions to RAM after an interrupt? Is it the PageManager, or does the LongTermScheduler wake up and do it? And is it only one page at a time?
• When a job is complete (all lines processed by the CPU), how can we let RAM or whoever know that those particular pages in RAM can be overwritten?

[mtfuller]

Answers

How can I determine the interrupt type (page fault or I/O), or will the CPU move the job to the appropriate queue in the Kernel?

I don't believe you will need to know the interrupt type. I've written the CPU to determine the interrupt type, and then place the PCB in appropriate queue. The DMA-Channel, which is now a Thread, will work to meet each I/O Request, moving data from RAM to the Cache, in the "I/O Queue"

Who actually writes the job's instructions to RAM after an interrupt? Is it the PageManager, or does the LongTermScheduler wake up and do it? And is it only one page at a time?

I had in mind that the PageManager would work through the "Page Fault queue", bringing the needed frames into RAM. I was thinking the PageManager could do this in a Java Thread, like the DMA-Channel. And I believe we are only to bring in one page at a time.

When a job is complete (all lines processed by the CPU), how can we let RAM or whoever know that those particular pages in RAM can be overwritten?

I thought that when a process is terminated, we could go through the PCB's Page Table and add those as "Free Frames" in the Free Frame pool in the Paging System. Perhaps, the Paging System could have a "Free Frame List" that could hold all the indexes of frames that could be used for a Page from disk.

Discussion

I think the process you wrote down sounds correct. I would only add that the Page Manager and DMA-Channel are working through every PCB that winds up on the I/O Queue or Page Fault Queue.

Does this answer your questions? Anything sound unclear? Do you feel like we need to set up a video chat to discus some of these issues?

-Thomas

[ghost]

No need for a video chat, this is great - thank you for the info! So I guess there should be a while loop in the PageManager that just constantly checks to see if anything's in the page fault queue? And if there is, it should bring one page of that particular job's instructions, is that right?

[mtfuller]

That is what I had in mind. Let me know if you have a better idea. I felt like the Page Manager could extend the Java Thread class, in order to run that while loop outside of the STS's execution. I would think it would be very similar logic to my DMA-Channel class from my Phase 2 branch. Does that make sense?

[ghost]

Yes, will work on that now - thanks again!

[mtfuller]

No prob! I'm trying to get the CPU finished up. Almost ready to start testing. GO TEAM!!!

[ghost]

I've updated my README. I only have the STS to complete now but have run into a problem with the findCpu() method. PageManager() is complete.

[mtfuller]

Great, I'm still getting some of the Test Classes for CPU and OS Modules worked out

[mtfuller]

I think that the OS module is finished. I think we just need to tweak some modules here and there in order to get the 4 CPUs to work together. Will close this until further notice.