It's UWAweek 29 (mid-year break)


This forum is provided to promote discussion amongst students enrolled in CITS2002 Systems Programming.
Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.
Displaying selected article
Showing 1 of 1168 articles.
Currently 2 other people reading this forum.

 UWA week 36 (2nd semester, mid-semester break) ↓
SVG not supported

Login to reply

5:16pm Mon 4th Sep, Christopher M.

> > If multiple processes can be unblocked at any time, they are unblocked (added to the READY queue) in the same order that they requested their action. > > Does this mean that whichever process was blocked first, is the one that is unblocked first? (if they can be unblocked at the same time).
Yes, exactly what it means.
> This sounds reasonable, but it adds a great level of complexity to the project. As we have multiple blocked queues, we would need to check every single blocked queue and not unblock anything until we confirm that no other processes can be unblocked. If there are other processes, we would need to compare when they were first put into the blocked queue. Adding such complexity for just a small edge case sounds unwarranted.
I cannot see where the perceived complexity comes from: - if we're talking about the queue of SLEEPING processes, because it's a *queue*, any sleeping processes that wake-up at the same time will all be at the exact from of the queue. - if we're talking about the WAITING queue, only one (parent) process can ever be unblocked when all of its children terminate. - if we're talking about the I/O BLOCKED queues , because only one process can be performing I/O at any one time, that process will always be at the head of its device's queue, and only that process will be unblocked.
> I was wondering if instead of this, we could just unblock in the same order as what happens when the CPU is idle. I have developed a solution already, and would need to make major changes if the clarifications were to be followed.
I'm confused by this comment. Things are only considered for unlocking when the CPU is idle.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  5:07AM Sep 06 2023
Privacy policy