Multiprogramming with Fixed Partitions in Memory - BunksAllowed

BunksAllowed is an effort to facilitate Self Learning process through the provision of quality tutorials.

Random Posts

Multiprogramming with Fixed Partitions in Memory

Share This

Monoprogramming is hardly ever utilized these days, save for on straightforward embedded devices. Multiple processes can operate simultaneously on the majority of modern computers. When several processes are active at once, another process can use the CPU while a blocked one waits for I/O to complete. Multiprogramming thus boosts CPU usage. Network servers can always execute many processes (for several clients) at once, but the majority of client (i.e., desktop) workstations today also have this capability.

Simply dividing memory into n (potentially uneven) divisions is the simplest technique to implement multiprogramming. For instance, when the system is booted up manually, this partitioning can be done.

A job can be added to the input queue for the smallest partition big enough to hold it when it comes in. The partitions in this method are fixed, therefore any space in a partition that isn't utilized by a work is lost. This system of fixed partitions and distinct input queues is seen in Fig. (a).


When the queue for a large partition is empty but the queue for a small partition is filled, as is the situation for partitions 1 and 3 in Fig. (a), it is evident that separating the incoming jobs into different queues has drawbacks. Despite the fact that there is lots of free memory, little jobs must wait to enter memory here. Maintaining a single queue, as in Fig. (b), is an alternate organizational structure. When a partition frees up, the work that fits in it and is closest to the front of the queue could be loaded and executed there.

When a partition becomes available, a different approach is to examine the entire input queue and select the largest work that fits because it is undesirable to use a large partition on a tiny project. Be aware that the latter approach treats little works unfairly by treating them as undeserving of a full partition while, in most cases, it is preferable to give the smallest jobs—often interactive jobs—the greatest service possible.

Having at least one small partition nearby is one method to escape. Small jobs can run on such a partition without requiring a huge partition to be set aside for them.

A restriction prohibiting skipping over a job more than k times for a job that is eligible to run is an alternative strategy. It receives one point for every time it is passed over. It cannot be skipped once it has accumulated k points.







Happy Exploring!

No comments:

Post a Comment