Case Study 6

OPERATING SYSTEMS

Case Study 6

Using the process state diagram, explain why there is no transition:
• From the READY to WAITING.
• From the WAITING to RUNNING.

No transition from READY to WAITING state.

What happens during READY state? During this state, A thread state is ready to run and waiting for scheduler to allot it a processor for running. This process is said to be ready if it is waiting to be assigned to a processor. This state can be reached only from ready state when the scheduler selects it for running.

What happens during WAITING state? Let’s state for example a state thread. A thread state is in waiting state when the thread blocks voluntarily. This state can be reached only from running state. A process is said to be blocked if it is waiting for some event to happen such that as an I/O completion before it can proceed. Note that a process is unable to run until some external event happens.

Reason/s why there is no transition from READY to WAITING state. Logically during the job and process status, an ordered path is followed in order to finish a process or a job wherein an entire job follows a series of steps which corresponds to different processes of the CPU (job scheduling, I/O request handling, interrupt handling, etc.). To sum it up, a READY state cannot proceed to the WAITING state not unless it had undergone through the RUNNING state.

No transition from WAITING to RUNNING state.

What Happens from READY to RUNING state? Ready State to Running State Occurs when all other processes have had their share and it is time for the first process to run again. This is where interrupts are issued. What happens when interrupts are issued? It is where the scheduler decides that the running process has run long enough and it is time to let another process have CPU time.

What happens during RUNNING state to WAITING state? Also called the “blocked state”. When process discovers that the RUNNING state cannot continue. If running process initiates an I/O operation before its allotted time expires, the running process voluntarily relinquishes the CPU.

True to be told, the job and process status follows ordered steps for a job to be done. In that case the RUNNING to WAITING state has transition trough initiation by job instruction while the WAITING state can only proceed to RUNNING state only during when it is time for the delayed job during running to continue the process before going again to RUNNING.

Case Study 5

OPERATING SYSTEMS

Case Study 5

Load the following jobs into memory using fixed partition following a certain memory allocation method (a. best-fit, b. first-fit, c. worst-fit).

a. Job1 (100k) f. Job6 (6k)

turnaround: 3 turnaround: 1

b. Job2 (10k) g. Job7 (25k)

turnaround: 1 turnaround: 1

c. Job3 (35k) h. Job8 (55k)

turnaround: 2 turnaround: 2

d. Job4 (15k) i. Job9 (88k)

turnaround: 1 turnaround: 3

e. Job5 (23k) j. Job10 (100k)

turnaround: 2 turnaround: 3

*turnaround – how long it will stay in the memory.

Worst Fit

First Fit

Best Fit

Case Study 4

OPERATING SYSTEMS

Case Study 4

Load the following jobs into memory using dynamic partition and relocatable dynamic partition: (The memory size is 220k with allocated OS for 15k).

a. Job1 (100k) f. Job6 (6k)

turnaround: 3 turnaround: 1

b. Job2 (10k) g. Job7 (25k)

turnaround: 1 turnaround: 1

c. Job3 (35k) h. Job8 (55k)

turnaround: 2 turnaround: 2

d. Job4 (15k) i. Job9 (88k)

turnaround: 1 turnaround: 3

e. Job5 (23k) j. Job10 (100k)

turnaround: 2 turnaround: 3

*turnaround – how long it will stay in the memory.

*apply compaction if only if the incoming jobs has no other block to allocate that will fit their sizes.

Dynamic Partition:

Relocatable Dynamic Partition

OPERATING SYSTEMS

Case Study 3

In a multiprogramming and time-sharing environment, several users share the system simultaneously. This situation can result in various security problems. Name at least two of these problems. Can we ensure the same degree of security in a time-share machine as we have in a dedicated machine? Explain your answer

No, because since any protection scheme devised by humans
can inevitably be broken by a human, and the more complex the scheme, the more difficult it is to feel confident of its correct implementation.

This is because in which a system which is consciously intended to have certain restricted purposes or functions becomes more and more elaborate over time, and more and more of its mechanisms become obscure and hidden in their inputs and outputs. I think maybe there are some natural examples of this kind of movement towards baroque complexity. But baroque complexity dies out when it becomes actively dysfunctional within some kind of fitness landscape. Human systems can achieve this kind of opacity by accident and by intent. Accidental drift towards a system where no one really understands how cause and effect work within the system happens in institutional life all the time. Stakeholders in individual parts or aspects of a system are inclined to expand the influence or size of their mechanism. New forces or powers outside an institution are often accommodated by being incorporated within it. Procedures or heuristics used by an institution in its everyday business sometimes take on a life of their own, especially when they are incorporated into technological infrastructure and automated in some respect. Complexity happens by intent when human agents with some degree of authority over an institutional system want to block off direct access or control to some of its inner workings as a safeguard against easy tampering. It also happens when someone with an interest in a particular system believes that secrecy and confusion will instrumentally advance that interest. I think there are quite a few examples of authorities who set out to make it hard for an outsider to understand how a system or process works only to find that in making it hard for outsiders to understand, they’ve made it hard for everyone, that even people in control who thought that secrecy would conceal selectively have found that it conceals indiscriminately.