Report Multiprocessor Scheduling Algorithm Implementation Using Genetic Algorithms

Narsee Monjee Institute of Management Studies
A Project Report on
Multiprocessor Scheduling Algorithm Implementation Using Genetic Algorithms

Submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor of Technology
Authors: Tanmaya Mahapatra Parth Bhalani Samarth Mittal
Supervisor: Dr. Nitin S.Choubey
April 30, 2012

Department of Computer Science, Mukesh Patel School of Technology Management & Engineering, NMiMS
Certicate
This is to certify that the project titled Multiprocessor Scheduling Implementation Using Genetic Algorithms is conducted and submitted for Trimester XII of Bachelor of Technology (Computer Engineering) as the partial fullment submission for the said degree by
Parth Bhalani (SET SHR080000045) Samarth Mittal (SET SHR080000051) Tanmaya Mahapatra (SET SHR080000253)
(Project Guide) Dr. N. S. Choubey
(Head of Dept.) Dr. N. S. Choubey
(Internal Examiner)
(External Examiner)
(Associate Dean) Dr. M.V. Deshpande
Declaration by Authors
We hereby declare that the Project report entitled Multiprocessor Scheduling Implementation Using Genetic Algorithms is an original work. The contents of the project report have not been published before and reect the work done by us during our academic year 2011-12 at Department of Computer Engineering, MPSTME, NMiMS, Shirpur. Borrowed ideas, graphics & quotations have been duly acknowledged.
Place :
Authors Date :
Acknowledgment
Firstly We would like to invoke the blessings of the Almighty without whose permission nothing is permissible in this world. We would like to express our sincere gratitude from the very inner core of our heart to Dr. Tapan Bagchi, Director, NMIMS Shipur Campus for providing us with positive criticism throughout the work which played a pivotal role in successful completion of this project. We would like to thank Dr. Nitin S. Choubey, Associate Professor & HOD (CS), our project guide whose words became our sole source of inspiration to complete the project in time. His constant encouragement, positive criticism helped us to progress in the right direction. We are extremely indebted to him for instilling in us the level of condence and showing what perseverance actually means. We would also like express our in-debt gratitude to Dr. M.V.Despande who made us feel that we were not alone at any stage of our work. Last but not the least we are also grateful to all faculty members of the Department of Computer Science and Engineering for their guidance and suggestions which ultimately culminated in the form of this nished project.
Abstract
In case of multiprogramming environment we can easily conclude that there are a number of processes or threads that compete for the resources or aptly for the CPU concurrently. There may be a number of processes in the READY state. The scheduler is responsible in deciding which process to run next. It makes use of complex algorithms to make the toughest decision. These algorithms called as Scheduling Algorithms have their own limitations because presence of real time information may at times render the decision made earlier useless. The traditional way of designing a complex Scheduling Algorithm to deal with complex real time issues does not suce. Since in a sense natural evolution is a process of continuous adaptation, it seems appropriate to consider Genetic Algorithms as good candidates for dynamic scheduling problems. We here make an attempt to study the dierent scheduling algorithms present, analyze their performance as well as their limitations and devise a scheduling algorithm based on GA to address these dynamic issues.
Contents
Page List of Figures List of Tables List of Listings List of Algorithms List of Abbreviations 1 Operating Systems 1.1 Introduction . . . . . 1.2 Components . . . . . 1.2.1 Kernel . . . . 1.2.2 Networking . 1.2.3 Security . . . 1.2.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v vii viii ix x 2 2 3 3 4 4 4 5 5 6 7 7 7 8 8 8 9 9 10 10 11
2 Process Scheduling 2.1 Introduction . . . . . . . . . . . . 2.1.1 Process Execution . . . . 2.2 Process Scheduling Algorithms . 2.2.1 FCFS Scheduling . . . . . 2.2.2 Round Robin Scheduling 2.2.3 Priority Scheduling . . . . 2.2.4 SJN Scheduling . . . . . . 2.2.5 Lottery Scheduling . . . .
3 Genetic Algorithms 3.1 Introduction . . . . . . . . . . . . . 3.2 Candidate Solution & Chromosome 3.2.1 Chromosome . . . . . . . . 3.3 Methodology . . . . . . . . . . . . ii
3.4
Initialization . . . . . . . . . . . . . . . . . . . . . . . Selection . . . . . . . . . . . . . . . . . . . . . . . . . Reproduction . . . . . . . . . . . . . . . . . . . . . . . 3.3.3.1 Crossover . . . . . . . . . . . . . . . . . . . . 3.3.3.1.1 Methods of selection of chromosomes for crossover . . . . . . . . . . . . . 3.3.3.1.2 Crossover Techniques . . . . . . . . 3.3.3.2 Mutation . . . . . . . . . . . . . . . . . . . . 3.3.4 Termination . . . . . . . . . . . . . . . . . . . . . . . . Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 3.3.2 3.3.3
11 12 12 12 13 13 15 16 18 19
4 Literature Survey 5 Process Scheduling Using GA 5.1 Introduction . . . . . . . . . . . . . . . . . 5.2 Problem Description . . . . . . . . . . . . 5.2.1 Assumption for Process Scheduling 5.3 GA Based Algorithm . . . . . . . . . . . . 5.3.1 Genotype . . . . . . . . . . . . . . 5.3.2 Initial Population . . . . . . . . . . 5.3.3 Fitness Function . . . . . . . . . . 5.3.4 Selection . . . . . . . . . . . . . . 5.3.5 Crossover . . . . . . . . . . . . . . 5.3.6 Inversion . . . . . . . . . . . . . . 5.3.7 Replacement Strategy . . . . . . . 5.3.8 Termination Condition . . . . . . . . . . . . . . . . . Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31 31 32 33 33 33 34 34 34 35 35 35 36 38 38 39 39 39 40 40 42 42 42 43 43 43 44 44 44 44
6 Software Engineering Aspects 6.1 System Analysis . . . . . . . . . . . . . . . . . 6.1.1 Requirements . . . . . . . . . . . . . . . 6.1.1.1 Functional Requirements . . . 6.1.1.2 Non-Functional Requirements 6.1.2 Analysis Diagrams . . . . . . . . . . . . 6.1.3 Architecture . . . . . . . . . . . . . . . 6.2 Hardware & Software Requirements . . . . . . 6.3 Development Plaftorm . . . . . . . . . . . . . . 6.3.1 Tools Used . . . . . . . . . . . . . . . . 6.4 Project Management . . . . . . . . . . . . . . . 6.4.1 Software Life Cycle . . . . . . . . . . . . 6.4.2 Process Model . . . . . . . . . . . . . . 6.4.3 Team Members Contribution . . . . . . 6.4.3.1 Parth Bhalani . . . . . . . . . 6.4.3.2 Samarth Mittal . . . . . . . . 6.4.3.3 Tanmaya Mahapatra . . . . . iii
6.4.4
Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44 46 46 47 47 47 49 49 50 51 51 52 52
7 Project Implementation 7.1 Implemented Modules 7.1.1 Main . . . . . . 7.1.2 Application . . 7.1.3 Applog . . . . 7.1.4 File I/O . . . . 7.1.5 Error Handler . 7.1.6 Scheduling . . 7.1.7 FCFS . . . . . 7.1.8 Round Robin . 7.1.9 SJN . . . . . . 7.1.10 Genetic . . . .
8 Testing & Deployment 53 8.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9 Simulation Results 58 9.1 Static Process Pool . . . . . . . . . . . . . . . . . . . . . . . . 58 9.2 Dynamic Process Pool . . . . . . . . . . . . . . . . . . . . . . 60 9.2.1 Graphs Explanation . . . . . . . . . . . . . . . . . . . 60 10 Concluding Remarks 75 10.1 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 References A Computational complexity A.1 P Complexity . . . . . . . A.2 NP Complexity . . . . . . A.3 NP - Complete . . . . . . A.4 NP - Hard . . . . . . . . . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 79 79 80 81 82 83
iv
List of Figures
1.1 2.1 3.1 3.2 3.3 3.4 3.5 5.1 5.2 6.1 6.2 6.3 8.1 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 Role of Operating System . . . . . . . . . . . . . . . . . . . . Scheduling Classication . . . . . . . . . . . . . . . . . . . . . Demonstration of Candidate One-point Crossover . . . . Two-point Crossover . . . . Cut and Splice . . . . . . . Three Parent Crossover . . Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6 11 14 14 14 15 35 36 40 41 45 55 63 63 64 64 65 65 66 66 67 67 68 68 69 69 70
Demonstration of Crossover . . . . . . . . . . . . . . . . . . . Demonstration of Inversion . . . . . . . . . . . . . . . . . . . Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . Gantt Chart for Project . . . . . . . . . . . . . . . . . . . . . Application Deployment . . . . . . . . . . . . . . . . . . . . . Static Pool - Process Arrival Pattern . . . . Static Pool - Process Arrival Pattern(log) . Static Pool - Average Wait Time . . . . . . Static Pool - Average Turn Time . . . . . . Process Arrival Pattern - 1st Iteration . . . Process Arrival Pattern(log) - 1st Iteration . Average Wait Time - 1st Iteration . . . . . Average Turn Time - 1st Iteration . . . . . Process Arrival Pattern - 2nd Iteration . . . Process Arrival Pattern(log) - 2nd Iteration Average Wait Time - 2nd Iteration . . . . . Average Turn Time - 2nd Iteration . . . . . Process Arrival Pattern - 3rd Iteration . . . Process Arrival Pattern(log) - 3rd Iteration Average Wait Time - 3rd Iteration . . . . . v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.16 9.17 9.18 9.19 9.20 9.21 9.22 9.23 9.24
Average Turn Time - 3rd Iteration . . . . . Process Arrival Pattern - 4th Iteration . . . Process Arrival Pattern(log) - 4th Iteration Average Wait Time - 4th Iteration . . . . . Average Turn Time - 4th Iteration . . . . . Process Arrival Pattern - 5th Iteration . . . Process Arrival Pattern(log) - 5th Iteration Average Wait Time - 5th Iteration . . . . . Average Turn Time 5th Iteration . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
70 71 71 72 72 73 73 74 74 81
A.1 Euler Diagram . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
List of Tables
4.1 8.1 9.1 9.2 9.3 Survey of Previous Work Done . . . . . . . . . . . . . . . . . Test Cases for Application Developed . . . . . . . . . . . . . Average Wait & Turn time - Static pool . . . . . . . . . . . . Average Waiting Time - Dynamic Pool . . . . . . . . . . . . . Average Turn Time - Dynamic Pool . . . . . . . . . . . . . . 20 56 59 61 62
vii
Listings
7.1 7.2 7.3 Applog Module Implementation . . . . . . . . . . . . . . . . . Error Handler Module Implementation . . . . . . . . . . . . . partial Scheduling Module Implementation . . . . . . . . . . . 48 49 50
viii
List of Algorithms
3.1 5.1 Genetic Algorithm Procedure . . . . . . . . . . . . . . . . . . Genetic Algorithm - Process Scheduling . . . . . . . . . . . . 16 36
ix
List of Abbreviations
CP U Central Processing Unit EA EC Evolutionary Algorithms Evolutionary Computation
EP S Encapsulated PostScript F CF S First Come First Serve GA Genetic Algorithms
GN U GNUs NOT UNIX I/O IP C NP OS Input/Output Inter-process Communication Non-Deterministic Polynomial-Time Hard Operating System
P DF Portable Document Format P N G Portable Network Graphics PS PostScript
SJN Shortest Job Next T P S Transactions Processed per Second
CHAPTER 1
Operating Systems
Computers are good at following instructions, but not at reading your mind. Donald Knuth
This chapter briey introduces to Operating Systems and its various components. A brief knowledge of Operating Systems is needed to grasp the fundamentals of process scheduling which in turn would help to understand the implemented project.
SECTION 1.1
Introduction
An Operating System is a special software that entirely manages the computers hardware resources and provides services needed by application software to run successfully. Every program like OpenOce or amaroK to run in a system requires some memory and may also have additional requirements. The main job of the operating system is to provide resources needed for these applications to run which includes but not necessarily limited to memory allocation. It often acts as an intermediary in handling the hardware. For example we have a document in post script format which we need to print using a printer attached to a system. Considering that the printer attached is a simple hardware which never understands any human languages used in the world. So here the main job of the OS is to help in running a special application software that translates this post script document into a format understandable by the printer and asks the printer to take a print i.e. a
1
CHAPTER 1. OPERATING SYSTEMS 3 User
Application
Operating System
Hardware Figure 1.1: Role of an Operating System hard copy of the document. Basic role of an operating System is depicted in Figure 1.1
SECTION 1.2
Components
An operating System has many dierent components which work together in a co-ordinated manner to achieve the desire functionality. All applications need to go through the OS in order to use the hardware. 1.2.1 Kernel It is the core of an Operating System. It is a bridge between applications and the actual data processing done at the hardware level. The kernels responsibilities include managing the systems resources (the communication between hardware and software components). A kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to application processes through inter-process communication mechanisms and system calls [3].
1.2. COMPONENTS
1
CHAPTER 1. OPERATING SYSTEMS 1.2.2 Networking Currently most operating systems support a variety of networking protocols, hardware, and applications for using them. This means that computers running dissimilar operating systems can participate in a common network for sharing resources such as computing, les, printers, and scanners using either wired or wireless connections [3]. 1.2.3 Security A computer being secure depends on a number of technologies working properly. A modern operating system provides access to a number of resources, which are available to software running on the system, and to external devices like networks via the kernel. The operating system must be capable of distinguishing between requests which should be allowed to be processed, and others which should not be processed. While some systems may simply distinguish between privileged and non-privileged, systems commonly have a form of requester identity, such as a user name. To establish identity there may be a process of authentication. Often a user name must be quoted, and each user name may have a password [3]. 1.2.4 User Interface Every computer that is to be operated by an individual requires a user interface. The user interface is not actually a part of the operating system. It generally runs in a separate program usually referred to as a shell 1 , but is essential if human interaction is to be supported [3] 4
A shell is a piece of software that provides an interface for users of an operating system which provides access to the services of a kernel.
1.2. COMPONENTS
2
CHAPTER 2
Process Scheduling
Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris. Larry Wall
This Chapter briey describes Process Scheduling and various traditional algorithms generally used for scheduling. Also enlisted are various criteria under which a scheduling decision is taken. The sources of information have also been indicated wherever appropriate.
SECTION 2.1
Introduction
Scheduling is making the choice of which process to run next when there are a number of processes in the READY state [27]. This is one of the scenarios frequently encountered in case of multiprogrammed environments. A number of processes or threads compete for the CPU concurrently. All scheduling problem are NP hard. The scheduling jobs have been broadly classied as either static or dynamic. See Figure 2.1 Static : The scheduling is said to be static when all the jobs are known before the processing starts. Dynamic : In this scenario then job release times are not xed and jobs arrive at dierent times.
CHAPTER 2. PROCESS SCHEDULING
Scheduling
2
Dynamic
Static
Figure 2.1: Scheduling Classification If all jobs are known before processing starts a scheduling problem is said to be static, while, to classify a problem as dynamic it is sucient that job release times are not xed at a single point in time, i.e. jobs arrive to the system at dierent times. Scheduling problems can also be classied as either deterministic, when processing times and all other parameters are known and xed, or as non-deterministic, when some or all parameters are uncertain [12]. 2.1.1 Process Execution In the case of batch processing systems the scheduling process was relatively straight forward. The scheduling algorithm just needed to run the next job. But this is not the case with modern multiprogrammed environments. Even today the type and nature of scheduling needed varies depending on the usage of system. Consider a case of a home user starting simultaneously a word processor and a music player, the scheduling of the processes do not matter very much because the end user is waiting for both the tasks to nish. But the situation changes dramatically when we consider a server. In this case there are multiple processes competing for the CPU. Resources are limited and scheduling decides whether to choose an important process or an unimportant one. CPU scheduling decisions may take under one of the following circumstances [23]: When a process goes from the running state to the wait state. When a process goes from the running state to the ready state. When a process goes from the wait state to the ready state. When a process terminates.
2.1. INTRODUCTION
CHAPTER 2. PROCESS SCHEDULING

SECTION 2.2
Process Scheduling Algorithms

The concept of scheduling stands valid only when a process terminates or it switches from the running state to the wait state. The scheduling scheme can again be categorized as either preemptive or non-preemptive. Under non-preemptive scheduling, once the CPU has been allocated to a process, the process keeps the CPU until it releases the CPU either by terminating or switching to the waiting state [23]. But in case of preemptive the CPU can be snatched away from the process and may be allocated to another process depending on : Expiration of time Quantum. Interrupts. High Priority jobs. 2.2.1 FCFS Scheduling This is the simplest of all the CPU scheduling algorithms [23]. The process requesting for the CPU rst is granted the CPU rst irrespective of all other conditions or criteria. When a process is currently using the processor other jobs may arrive which are stored in a FIFO queue. When the process nishes the dispatcher simply selects the process rst in the FIFO queue and allocates it the CPU. There are certain shortcomings in this type of scheduling like a small process may have to wait for a very longer period of time till one large job nishes. This eect is termed as Convoy eect. 2.2.2 Round Robin Scheduling The Round-Robin scheduling algorithm is designed especially for time sharing systems. It is similar to FCFS scheduling but preemption is added to switch between processes. A small unit of time, called a time quantum or time slice is dened [23]. Basically the process is allocated the CPU for the dened time quantum, After the expiry of the timer a process switch takes place where by the CPU is allocated to the next process in the queue. The ready queue used for storing the processes or jobs arriving at dierent time instances is basically a FIFO queue. 2.2.3
2.2. PROCESS SCHEDULING ALGORITHMS
CHAPTER 2. PROCESS SCHEDULING Priority Scheduling
In round robin we implicitly assume that all processes are equal but here taking external factors into account we give priorities to the processes taking external factors into account. A single user PC also has many processes, some are more important than others, so we need to arrange them according to various priorities. 2.2.4 SJN Scheduling This algorithm associates with each process the length of the processs next CPU burst. When the CPU is available, it is assigned to the process that the smallest next CPU burst [23]. This reduces the average waiting time of the processes and eradicates the Convoy eect as seen in the FCFS scheduling algorithm. But there may be circumstances where we encounter two or more processes with exactly the same CPU burst time. In such cases FCFS scheme is often used to decide which process should be allocated the CPU rst. 2.2.5 Lottery Scheduling In this the basic idea is to give lottery tickets for various resources like CPU time, to various processes. Whenever, scheduling has to be done, a lottery ticket has to be chosen at random and the process holding that ticket gets the resource.
2.2. PROCESS SCHEDULING ALGORITHMS
CHAPTER 3
Genetic Algorithms
The trouble with programmers is that you can never tell what a programmer is doing until its too late. Seymour Cray
This chapter basically discusses the basic aspects of Genetic Algorithms which we have studied and this further helped to successfully design a scheduling algorithm using GA. The sources of information have also been indicated wherever appropriate.
SECTION 3.1
Introduction
Genetic Algorithms are a class of heuristic algorithms which operate in a fashion quite similar to natural evolution. These algorithms were rst proposed by Holland in 1975. In Genetic Algorithms there is no unique way of solving a particular problem. It can be applied in many elds. Initially the solution space contains some solutions generated in any way possible. But when the algorithm iterates it keeps on generating more solutions and keeps the optimum results while discarding the less optimum solution space. It can be viewed as a sequence of permutation and combination. It belongs to the larger class of EA1 . It generates solutions to various optimization problems involving a number of methods which essentially mimic the biological evolution process. Some of the methods are :
1 An evolutionary algorithm (EA) is a subset of evolutionary computation, a generic population-based meta-heuristic optimization algorithm
CHAPTER 3. GENETIC ALGORITHMS Inheritance Mutation Crossover Selection
10
Before discussing the general methodology involved in Genetic Algorithms we would be rst discussing about Candidate Solutions & Chromosomes. That would be quite illuminating for understanding the underlying mechanism.
SECTION 3.2
Candidate Solution & Chromosome

In optimization , a candidate solution is a member of a set of possible solutions to a given problem. A candidate solution need not be the most optimal or reasonable solution to the problem - it is simply in the set that satises all constraints. The space of all candidate solutions is called the feasible region , feasible set , search space , or solution space . In the case of the genetic algorithm, the candidate solutions are the individuals in the population being evolved by the algorithm [1]. Feasible region is shown in Figure 3.1 3.2.1 Chromosome In genetic algorithms, a chromosome 2 is a set of parameters which dene a proposed solution to the problem that the genetic algorithm is trying to solve. The chromosome is often represented as a simple string, although a wide variety of other data structures are also used [3]. For chromosome design refer to Example 3.2.1 . Example 3.2.1. In the travelling salesman problem, we seek an ordered list of cities that results in the shortest trip for the salesman to travel. Suppose there are six cities, which well call A, B, C, D, E, and F. A good design for our chromosome might be the ordered list we want to try. An example chromosome we might encounter in the population might be DFABEC [3].
Also called as a genome
3.2. CANDIDATE SOLUTION & CHROMOSOME
CHAPTER 3. GENETIC ALGORITHMS
11
3
Figure 3.1: A series of linear programming constraints on two variables produces a region of possible values for those variables. Solvable problems will have a feasible region in the shape of a simple polygon [1].
SECTION 3.3
Methodology
In Genetic Algorithms the chromosomes which have an initial solution evolve in a manner similar to biological evolution and give ner optimal results. In other words they encode candidate solutions. The solutions can be encoded using simple 1s and 0s but various other encoding schemes have also been used. The generation starts with a random candidate solution and iterates. After every generation the tness of every individual in the population is calculated. Multiple individuals are selected based on their tness and mutated to form new population. This new population so formed is used in the next generation. The algorithm iterates in this fashion till a predened number of iterations is attained or a satisfactory tness level has been achieved. The tness level is computed using a tness function3 . A Genetic algorithm basically requires : Genetic Representation A Fitness Function. 3.3.1 Initialization Initially many individual solutions are randomly generated to form an initial population. The population size depends on the nature of the problem, but
3 A tness function is a particular type of objective function that is used to summarize, as a single gure of merit, how close a given design solution is to achieving the set aims. 4 Genetic representation is a way of representing solutions/individuals in evolutionary computation methods.
of the Problem Domain.
3.3. METHODOLOGY
12
typically contains several hundreds or thousands of possible solutions. Traditionally, the population is generated randomly, allowing the entire range of possible solutions (the search space). 3.3.2 Selection During each successive generation, a proportion of the existing population is selected to breed a new generation. Individual solutions are selected through a tness-based process, where tter solutions (as measured by a tness function) are typically more likely to be selected. Certain selection methods rate the tness of each solution and preferentially select the best solutions. Other methods rate only a random sample of the population, as the latter process may be very time-consuming. 3.3.3 Reproduction The next step is to generate a second generation population of solutions from those selected through genetic operators: crossover 5 and/or mutation. For each new solution to be produced, a pair of parent solutions is selected for breeding from the pool selected previously. By producing a child solution using the above methods of crossover and mutation, a new solution is created which typically shares many of the characteristics of its parents. New parents are selected for each new child, and the process continues until a new population of solutions of appropriate size is generated. Although reproduction methods that are based on the use of two parents are more biology inspired, some research [28] [11] suggests that more than two parents generate higher quality chromosomes. Although Crossover and Mutation are known as the main genetic operators, it is possible to use other operators such as regrouping , colonization-extinction , or migration in genetic algorithms [4].

3.3.3.1 Crossover
Crossover is a genetic operator used to vary the programming of a chromosome or chromosomes from one generation to the next. It is very similar to reproduction and biological crossover, upon which genetic algorithms are based. Cross over is a process of taking more than one parent solutions and producing a child solution from them. The methods for selection of the chromosomes are :
5
Also called recombination
3.3. METHODOLOGY
CHAPTER 3. GENETIC ALGORITHMS 3.3.3.1.1 Methods of selection of chromosomes for crossover
13
Roulette wheel selection The simplest selection scheme is roulettewheel selection 6 The individuals are mapped to contiguous segments of a line, such that each individuals segment is equal in size to its tness. A random number is generated and the individual whose segment spans the random number is selected. The process is repeated until the desired number of individuals is obtained (called mating population). This technique is analogous to a roulette wheel with each slice proportional in size to the tness [7]. 3.3.3.1.2 Crossover Techniques
The widely used crossover techniques have been discussed below. One-point crossover A single crossover point on both parents organism strings is selected. All data beyond that point in either organism string is swapped between the two parent organisms. The resulting organisms are the children. Refer to Figure 3.2 Two-point crossover Two-point crossover calls for two points to be selected on the parent organism strings. Everything between the two points is swapped between the parent organisms, rendering two child organisms. Refer to Figure 3.3 Cut and splice In the cut and splice approach, there is a change in length of the children strings. The reason for this dierence is that each parent string has a separate choice of crossover point. Refer to Figure 3.4 Uniform Crossover and Half Uniform Crossover The Uniform Crossover uses a xed mixing ratio between two parents. Unlike one and two point crossover, the Uniform Crossover enables the parent chromosomes to contribute the gene level rather than the segment level. Three parent crossover In this technique, the child is derived from three parents. They are randomly chosen. Each bit of rst parent is checked with bit of second parent whether they are same. If same then the bit is taken for the ospring otherwise the bit from the third parent is taken for the ospring. For example refer to Figure 3.5
6
Also called as stochastic sampling with replacement.
3.3. METHODOLOGY
14
3
Figure 3.2: One-point Crossover [3]
Figure 3.3: Two-point Crossover [3]
Figure 3.4: Cut and Splice [3]
3.3. METHODOLOGY
15
3
Figure 3.5: Three Parent Crossover [26]

3.3.3.2 Mutation
Mutation is a genetic operator used to maintain genetic diversity from one generation of a population of algorithm chromosomes to the next. It is analogous to biological mutation. Mutation alters one or more gene values in a chromosome from its initial state. In mutation, the solution may change entirely from the previous solution. Hence GA can come to better solution by using mutation. Mutation occurs during evolution according to a userdenable mutation probability. This probability should be set low. If it is set to high, the search will turn into a primitive random search. Bit string mutation The mutation of bit strings ensue through bit ips at random positions. The probability of a mutation of a bit is 1 l , where l is the length of the binary vector. Flip Bit the bits7 . This mutation operator takes the chosen genome and inverts
Boundary This mutation operator replaces the genome with either lower or upper bound randomly. This can be used for integer and oat genes. Uniform This operator replaces the value of the chosen gene with a uniform random value selected between the user-specied upper and lower bounds for that gene. This mutation operator can only be used for integer and oat genes.
7
If the genome bit is 1,it is changed to 0 and vice versa
3.3. METHODOLOGY
16
Non-Uniform The probability that amount of mutation will go to 0 with the next generation is increased by using non-uniform mutation operator. It keeps the population from stagnating in the early stages of the evolution.It tunes solution in later stages of evolution. This mutation operator can only be used for integer and oat genes. 3.3.4 Termination The generational process is repeated until a termination condition has been reached. Common terminating conditions are: A solution is found that satises minimum criteria. Fixed number of generations reached. Allocated budget (computation time/money) reached. The highest ranking solutions tness is reaching or has reached a plateau such that successive iterations no longer produce better results. Manual inspection or combinations of the above. For General GA algorithm and Pseudo-code refer to Algorithm 3.1 and Pseudo-Code 1 respectively. Algorithm 3.1 Simple Genetic Algorithm procedure 1. Choose the initial population of individuals. 2. Evaluate the tness of each individual in that population. 3. Repeat on this generation until termination (time limit, sucient tness achieved, etc.): (a) Select the best-t individuals for reproduction. (b) Breed new individuals through crossover and mutation operations to give birth to ospring. (c) Evaluate the individual tness of new individuals. (d) Replace least-t population with new individuals
3.3. METHODOLOGY
17
PSeudo-Code 1 General GA Pseudo-code M ax individuals pop = pop[M ax] Choose the initial population of individuals f it = f it[M ax] counter 0 for all pop do Evaluate the tness of each individual f itness(pop[counter]) counter counter + 1 end for while term = true do counter 0 for all pop do Select the Best Fit bf pop best f it(pop[counter]) counter counter + 1 end for crossover(bf pop) Breed new individuals - Crossover mutation(bf pop) Breed new individuals - Mutation counter 0 for all bfpop do Evaluate the tness of each individual f it[counter] f itness(bf pop[counter]) counter counter + 1 end for for all bfpop do Replace least-t population if f it[counter] > f itness level then pop[counter] bf pop[counter] counter counter + 1 else counter counter + 1 continue end if end for end while
3.3. METHODOLOGY

SECTION 3.4
18
Criticism
There are several criticisms of the use of a genetic algorithm compared to alternative optimization algorithms. Some of them are : In many problems, GAs may have a tendency to converge towards local optima or even arbitrary points rather than the global optimum of the problem. The better solution is only in comparison to other solutions. As a result, the stop criterion is not clear in every problem. Genetic algorithms do not scale well with complexity. That is, where the number of elements which are exposed to mutation is large there is often an exponential increase in search space size. This makes it extremely dicult to use the technique on problems such as designing an engine, a house or plane. In order to make such problems tractable to evolutionary search, they must be broken down into the simplest representation possible[26]. Operating on dynamic data sets is dicult, as genomes begin to converge early on towards solutions which may no longer be valid for later data. GAs cannot eectively solve problems in which the only tness measure is a single right/wrong measure (like decision problems), as there is no way to converge on the solution (no hill to climb). In these cases, a random search may nd a solution as quickly as a GA [3].
3.4. CRITICISM
CHAPTER 4
Literature Survey
Without requirements or design, programming is the art of adding bugs to an empty text le. Louis Srygley
Genetic algorithm is one of the widely used techniques for constrain optimization. Genetic algorithm is basically search algorithm based on natural selection and natural genetics. This chapter briey describes the literature survey done of previous work done in the eld of CPU Process Scheduling using Genetic Algorithm. This literature survey is a table of text that aims to review the critical points of current knowledge including substantive ndings as well as theoretical and methodological contributions to our. It does not report any new or original experimental work. Basing on the ideas collected from the table given in the next page we make our proposal in the next chapter. For Literature Survey refer to Table 4.1 and for proposal of the work to be done refer to Chapter 5.
19
CHAPTER 4. LITERATURE SURVEY
Table 4.1: Survey of Previous Work Done in Process Scheduling using Genetic Algorithms. S/L No. 1. Paper Details Title : A Modied Genetic Algorithm for Process Scheduling in Distributed System Authors : Vinay Harsora & Apurva Shah Work Done Contributions Scheduling in distributed operating system has a signicant role in overall system performance and throughput [14]. They have presented and evaluated new genetic algorithm based method to solve this problem in a way that simultaneously minimizes scheduling length and maximize average processor utilization. It also minimizes the computation time of genetic algorithm. Limitations Most of the existing solutions tend to focus only one of the objectives but they have simultaneously dealt with all the three [14].
Continued on next page
20
S/L No. 2.
Table 4.1 continued from previous page Paper Details Work Done Title : A Hybrid Grouping Ge- Contributions netic Algorithm for Multiprocessor Scheduling This paper describes a hybrid grouping genetic algoAuthors : Alok Singh, Marc Serithm for a multiprocessor scheduling problem, where vaux & Andr e Rossi a list of tasks has to be scheduled on identical parallel processors. The objective is to minimize the number of processors used while respecting the constraints imposed by release dates and due dates [25]. Limitations Can be extended - hybrid approach to the version of the problem where there are precedence constraints among tasks.
21
S/L No. 3.
Table 4.1 continued from previous page Paper Details Work Done Title : Genetic Algorithm approach Contributions to Operating system process scheduling problem In this paper , they use the power of genetic algorithm Authors : Dr. Rakesh Kumar, to provide the ecient process scheduling. Er. Rajiv Kumar, Er. Sanjeev Gill & Er. Ashwani Kaushik The aim is to obtain an ecient scheduler to allocate and schedule the process to CPU [17]. Limitations The work can be extended so that technique can be implemented for dynamic process scheduling and sequencing. The performance can also increase by apply diploidy operator on this problem [17].
22
S/L No. 4.
Table 4.1 continued from previous page Paper Details Work Done Title : Using Genetic Algorithms Contributions for Dynamic Scheduling Authors : Ana Madureira, Carlos Deals with Dynamic nature of Scheduling problems. Ramos & Silvio do Carmo Silva Uses Genetic Algorithm to Solve these. Has used vertical oriented EJSSP for analysis [18]. Limitations No benchmark performed with other existing methodologies. None of the existing works has explicitly addressed EJSSP. It is dicult to nd test problems and computational results for dynamic environments [18].
23
S/L No. 5.
Table 4.1 continued from previous page Paper Details Work Done Title : A Novel Genetic Algorithm Contributions for Static Task Scheduling in Distributed Systems In this paper, a new genetic algorithm, named Authors : Amir Masoud Rahmani TDGASA, is presented which its running time depends & Mojtaba Rezvani on the number of tasks in the scheduling problem. Then, the computation time of TDGASA to nd a suboptimal schedule is improved by Simulated Annealing (SA) [21]. Limitations There is a tradeo between the computation time and the total completion time. But with the proper using of simulated annealing, the computation time of the algorithm decreases more, although, the overall completion time is not increased [21].
24
S/L No. 6.
Table 4.1 continued from previous page Paper Details Work Done Title : Genetic algorithm Approach Contributions for Optimal CPU Scheduling Authors : Preeti Sindhwani & This Paper contains how we can use genetic algorithm Vaishali Wadhwa in nding an innovative solution for CPU Scheduling. Using an ecient encoding, and designing appropriate crossover and mutation operators for our problem may achieve this. The algorithm requires a population of individuals. Limitations The work can be extended so that technique can be implemented for dynamic process scheduling and sequencing. The performance can also increase by apply diploidy operator on this problem [24].
Continued on next page 25
S/L No. 7.
Table 4.1 continued from previous page Paper Details Work Done Title : A Performance Study of Contributions GA and LSH in Multiprocessor Job Scheduling This paper proposes a comparison study of genetic alAuthors : Mrs. S. R. Vijayalakgorithm and list scheduling algorithm. shmi & Dr. G. Padmavathi Both algorithms are naturally parallelizable but have heavy data dependencies. Based on experimental results, this paper presents a detailed analysis of the scalability, advantages and disadvantages of each algorithm. Limitations This paper compares scheduling algorithms for multiprocessor task scheduling [29]. It concludes that from a purely performance point of view, Genetic algorithm is the best solution, but its deployment needs to be subject of a careful cost benet analysis [29]. It concludes that list scheduling will be suggested for the less number of tasks and processors.
26
S/L No. 8.
Table 4.1 continued from previous page Paper Details Work Done Title : Dynamic Task Scheduling Contributions Using Parallel Genetic Algorithms For Heterogeneous Distributed A parallel genetic algorithm has been developed to Computing dynamically schedule heterogeneous tasks to heteroAuthors : R.Nedunchelian, geneous processors in a distributed environment [19]. K. Koushik, N. Meiyappan & V. Raghu The proposed algorithm uses multiple processors with centralized control for scheduling. Limitations The Algorithm can be extended. The proposed algorithm uses a straightforward encoding scheme and generates a randomized initial population [19].
27
S/L No. 9.
Table 4.1 continued from previous page Paper Details Work Done Title : A Novel Adaptive Neuro Contributions Fuzzy Inference System Based CPU Scheduler for Multimedia Operating Proposed a novel CPU Scheduler based on Adaptive System Neuro Fuzzy Inference System (ANFIS), to support Authors : Mohammad Atique & the execution of multimedia applications along with Mir Sadique Ali conventional applications in multimedia operating system. A simulator is developed in MATLAB 7.2.0.232 & the performance of the proposed scheduler is evaluated against the existing algorithms [6]. It is demonstrated that, the proposed scheduler is able to optimize various CPU scheduling parameters as well as resource utilization. Limitations Future scope of the work includes the use of other articial neural network model for processor scheduling [6].
28
S/L No. 10.
Table 4.1 continued from previous page Paper Details Work Done Title : Scheduling in Multipro- Contributions cessor System Using Genetic Algorithms This paper investigates dynamic scheduling of realAuthors : Edwin H. S. Hou, Nirtime tasks in a multiprocessor system to obtain a wani Ansari & Hong Ren feasible solution using genetic algorithms combined with well-known heuristics, such as Earliest Dead line First and Shortest Computation Time First. A comparative study of the results obtained from simulations shows that genetic algorithm can be used to schedule tasks to meet deadlines, in turn to obtain high processor utilization. Limitations Employment Processing technique in multiprocessor computing domain.
29
S/L No. 11.
Table 4.1 continued from previous page Paper Details Work Done Title : A Performance Evaluation Contributions of Multiprocessor Scheduling with Genetic Algorithm This paper addresses the problem of multiprocessor Authors : ReaKook Hwanga, Mitscheduling represented as a directed acyclic task graph suo Gen & Hiroshi Katayama (DAG) without communication costs to fully connected multiprocessors. They proposed an algorithm, called PGA/SPF (Priority-based Genetic Algorithm/Shortest Processor First schedule) where a priority-based genetic algorithm is improved with the introduction of some knowledge about the scheduling problem, which is represented by the use of genetic operators as crossover and mutation operators [16]. Limitations No precise conclusions from the authors or inferences that the work can be improved or fails at some situations.
30
CHAPTER 5
Process Scheduling Using GA

Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program. Linus Torvalds
This chapter describes the implementation of Genetic Algorithm for Operating System process scheduling. Scheduling in Operating System has a signicant role in overall System performance and throughput 1 . An ecient scheduling is vital for System performance. The scheduling is considered as NP hard problem. In this chapter, we use the power of Genetic Algorithm to provide ecient process scheduling. The aim is to obtain an ecient scheduling algorithm which would schedule the processes to the CPU with minimum waiting time 2 .
SECTION 5.1
Introduction
Scheduling in the operating system is a critical factor in the overall system eciency [20]. Process scheduling in an operating system can be stated
It is the number of processes that complete their execution per time unit [3]. The amount of work performed by a computer within a given time. It is a combination of internal processing speed, peripheral speeds (I/O) and the eciency of the operating system, other system software and applications all working together. Transactions processed per second (TPS) is one metric commonly used to gauge throughput [2]. 2 It is the amount of time that a process spends waiting for the CPU in the ready queue [3].
1
31
CHAPTER 5. PROCESS SCHEDULING USING GA
32
as allocating processes to the processor so that throughput & eciency of the system will be maximized. Typically scheduling problems are NP Hard problems [9]. There is necessity to nd out robust & exible solution for the real world scheduling problem. Genetic Algorithm is a promising global optimization technique [13]. It works by emulating the natural process of evolution as a means of progressing towards the optimal solution. A Genetic Algorithm has the capability to nd out the optimal job sequence which is to be allocated to the CPU. This chapter presents the Genetic Algorithm based technique to nd out the optimal job sequence. We would be examining whether Genetic Algorithm based scheduling will maximize the operating system performance or not. The algorithm starts with a population which consists of several solutions to the optimization problem. A member of population is called an individual. A tness value is associated with each individual. Each solution in the population or an individual is encoded as a string of symbols . These symbols are known as genes & the solution string is called a chromosome 3 . The values taken by genes are called alleles 4 . Several pair of individuals (parents) in the population mate to produce ospring by applying the genetic operator - crossover . Selection of parents is done by repeated use of a choice function. A number of individuals & o springs are passed to a new generation such that the number of individual in the new population is the same as old population. A selection function 5 determines which string forms the population in the next generation. Each serving string undergoes inversion 6 with a specied probability.
SECTION 5.2
Problem Description
In order to schedule the process in a uni-processor as well as a multiprocessor operating system let us suppose that there are N processes (1,2,3,. . . N ) and these processes have their static burst time. These processes need to be processed on a single CPU at a time. The aim is to nd out optimal process sequence [5] by which the processes can be scheduled [8] in such a way that total waiting time is minimum. 5.2.1
For More information on Chromosome, refer Section 3.2.1 An allele is one of two or more forms of a gene. 5 For more information on Selection Functions, refer Section 3.3.2 6 An inversion is a chromosome rearrangement in which a segment of a chromosome is reversed end to end. An inversion occurs when a single chromosome undergoes breakage and rearrangement within itself.
4 3
5.2. PROBLEM DESCRIPTION
CHAPTER 5. PROCESS SCHEDULING USING GA Assumption for Process Scheduling Problem
33
There is a pool of ready processes waiting for the allocation of CPU. The processes are independent and compete for the allocation of resources. The job of the proposed scheduling algorithm is to distribute the resource i.e. CPU to dierent processes fairly so that performance criteria must be optimal i.e. minimum average waiting time. The initial population of individual solutions are randomly generated.
SECTION 5.3
GA Based Algorithm
Genetic algorithms, powerful & broadly applicable stochastic research techniques, are the most widely known type of evolutionary computation method today. In general, a genetic algorithm has ve basic components as follows [15]: An encoding method that is a genetic representation - genotype of solutions to the program. A way to create an initial population of individuals - chromosome . An evaluation function, rating solution in terms of their tness, & a selection mechanism. The genetic operators (crossover & inversion ) that alter the genetic composition of ospring during reproduction. Values for the parameter of Genetic Algorithm. 5.3.1 Genotype In the GA based algorithms each chromosome corresponds to a solution to the problem. The genetic representation of the individual is called Genotype . Many Genotypes have been proposed in [15]. Here we represent a chromosome with the combination of ve decimal numbers. Here sequence of ve decimal number is the number of jobs. E.g. (2,4,1,3,5) sequence of ve jobs or processes.
5.3. GA BASED ALGORITHM
CHAPTER 5. PROCESS SCHEDULING USING GA 5.3.2 Initial Population
34
A Genetic Algorithm starts with a set of individuals called initial population. Most GA based algorithms generate initial population randomly. Here individual solutions are randomly generated with function to form an initial population. In the simulation initial population with size of POPSIZE is generated with function. 5.3.3 Fitness Function The main objective of GA is to nd an optimal solution. In order to nd the optimal solution a tness function must be devised for the problem under consideration i.e. Fit (Popcurrent). For a particular chromosome, the tness function returns a single numerical tness, or gure of merit, which is supposed to be proportional to the utility or ability of the individual which that chromosome represent. Here the tness of the individual is nd out on the basis of minimum average waiting time. Those individuals who have minimum average waiting time are the ttest as compared to other. The ttest individuals have the capability to participate in the reproduction cycle. The tness function of a Schedule Sj is given by Equation 5.1.
N
W ti (5.1) N where t is the job schedule; Wt1 is the waiting time of process J1 , Wt2 for J1 and so on. N is the total number of processes. F itness(Sj ) =
i=1
5.3.4 Selection The selection process used here is based on spinning the roulette wheel, which each chromosome in the population has slot size in proportion to its tness. Each time we require an ospring, a simple spin of the weighted roulette wheel gives a parent chromosome. The probability Pi that a parent Si is given by Equation 5.2. Pi = F (Si )
P OP SIZE
(5.2)
j =1
F (Sj )
Where F(Si ) is the tness of chromosome Si .
CHAPTER 5. PROCESS SCHEDULING USING GA 5.3.5 Crossover
35
Crossover is generally used to exchange portions between strings. Several crossover operators are described in the literature [22]. Crossover is not always aected; the invocation of the crossover depends on the probability of the crossover. Modied crossover [10] is used in this simulation. Modied crossover operator is an extension of the one point crossover for permutation problems. A cut position is chosen at random on the rst parent chromosome. Then an ospring is created by appending the second chromosome to the initial part of the rst parent(before the cut point) and eliminating the duplicates. See Figure 5.1
5
Figure 5.1: Demonstration of Crossover Process 5.3.6 Inversion Inversion is a process in which the order of two gene position is swapped with respect to each other. In inversion operator two points are selected along the length of the chromosome, the chromosome is cut at those points and the end points of the section cut, gets reversed(swapped). To make it clear, we consider a chromosome of length 5, where two inverse points are selected randomly. See Figure 5.2 5.3.7 Replacement Strategy When genetic operators (Modied crossover, inversion ) are applied on the selected parents S1,S2 one new chromosome is generated. This chromosome is added to the existing population. After that tter chromosomes are se-
36
Figure 5.2: Demonstration of Inversion Process lected from the new population. This process continues until we do not get optimal solution. 5.3.8 Termination Condition There are multiple choices for termination condition: Maximum number of generations, algorithm convergence, equal tness for ttest selected chromosomes in respective iteration. For Algorithm and Pseudo-code for the above mentioned method refer to Algorithm 5.1 & Pseudo-code 2 Algorithm 5.1 Implemented Genetic Algorithm for Process Scheduling 1. Choose the initial population of individuals. 2. Evaluate the tness of each individual in that population. 3. Repeat on this generation until termination (sucient tness achieved or max generations): (a) Selection the best-t individuals for reproduction using Roullete wheel Selection (b) Breed new individuals through Modied crossover to give birth to ospring. (c) Evaluate the individual tness of new individuals. (d) Replace least-t population with new individuals.
37
PSeudo-Code 2 Implemented GA Pseudo-code M ax individuals pop = pop[M ax] Choose the initial population of individuals f it = f it[M ax] counter 0 for all pop do Evaluate the tness of each individual f itness(pop[counter]) counter counter + 1 end for while term = true do counter 0 for all pop do Select the Best Fit - Roulette Wheel Selection bf pop roulette wheel(pop[counter]) counter counter + 1 end for mcrossover(bf pop) Breed new individuals - Modied Crossover counter 0 for all bfpop do Evaluate the tness of each individual f it[counter] f itness(bf pop[counter]) counter counter + 1 end for for all bfpop do Replace least-t population if f it[counter] > f itness level then pop[counter] bf pop[counter] counter counter + 1 else counter counter + 1 continue end if end for end while
CHAPTER 6
Software Engineering Aspects

Perfection [in design] is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exup ery
SECTION 6.1
System Analysis
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conicting requirements of the various stakeholders, such as beneciaries or users. It is an early stage in the more general activity of requirements engineering which encompasses all activities concerned with eliciting, analyzing, documenting, validating and managing software or system requirements .Requirements analysis is critical to the success of a systems or software project. The Requirements should be documented, actionable, measurable, testable, traceable, related to identied business needs or opportunities, and dened to a level of detail sucient for system design. 6.1.1
38
CHAPTER 6. SOFTWARE ENGINEERING ASPECTS Requirements
39
The various functional and non-functional requirements have been described below.

6.1.1.1 Functional Requirements

In software engineering, a functional requirement denes a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. The various Functional Requirements of the proposed application are: FCFS Module should schedule the pool of processes in rst come rst serve basis. Input should be process details with their arrival & burst time. Output should be a le contating scheduled details. SJN Module should schedule the pool of processes in order of shortest job remaining rst. Input should be process details with their arrival & burst time. Output should be a le contating scheduled details. Genetic Module should schedule the pool of processes in accrodance with the proposed algorithm. Input should be process details with their arrival & burst time. Output should be a le contating scheduled details. Round Robin Module should schedule the pool of processes as per the dened time quantum in a pre-emptive manner. Input should be process details with their arrival & burst time. Output should be a le contating scheduled details.

6.1.1.2 Non-Functional Requirements

In systems engineering and requirements engineering, a non-functional requirement is a requirement that species criteria that can be used to judge the operation of a system, rather than specic behaviors.In general, functional requirements dene what a system is supposed to do whereas nonfunctional requirements dene how a system is supposed to be.
6.1. SYSTEM ANALYSIS
CHAPTER 6. SOFTWARE ENGINEERING ASPECTS 6.1.2 Analysis Diagrams
40
6
Figure 6.1: Activity Diagram
6.1.3 Architecture
CHAPTER 6. SOFTWARE ENGINEERING ASPECTS
41
6
Figure 6.2: State Diagram

SECTION 6.2
42
Hardware & Software Requirements

The following are the requirements for running the Application developed : 1. Hardware Requirements Minimum 32 MB of Ram. 166Mhz Intel Pentium processor or any other equivalent family of processor. 2. Software Requirements Linux or any other Unix family of OS. GNU Make and GCC required to compile the Source code.
SECTION 6.3
Development Plaftorm
The Application is developed on Debian Squeeze running Linux Kernel 2.6.32-5. The executable produced can be run on any Unix like Operating System. 6.3.1 Tools Used GIT The goal is usually less about code quality and more about exploring possibilities. Academic code is often quite crude, hacked together by us student(s), with dozens of false starts and changes in requirements. Trying to recreate previous experiments is often very dicult unless the previsions are made for such rollbacks. And if we have, its probably done in a way that seemed logical to us at the time but is a nightmare for someone new to the project. There are ways to avoid this, by placing more of an emphasis on software engineering, but sometimes projects are so small or short-lived that it doesnt seem feasible to trouble with that at rst. To help combat these issues, we have used git. Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. Doxygen Doxygen is a tool for writing software reference documentation. The documentation is written within code, and is thus relatively easy to keep up to date. Doxygen can cross reference documentation and code, so that the reader of a document can easily refer to the actual code. We have extensively used doxygen to document the API. 6.2. HARDWARE & SOFTWARE REQUIREMENTS
43
LaTeX LaTeX is used for documenting the project as well as for creating the presentation. The Beamer class in LaTeX is used for presentations. Dia & Inkscape These two tools are also open sourced under GNU Public license and were used for the creating UML diagrams and gures listed in the list of gures. GCC The GNU Compiler collection is used for compiling the C Codes written with the help of GNU Make. Emacs GNU Emacs has been used as the editor both for source code development as well as LaTeX preparation.
SECTION 6.4
Project Management
The Project Management stu was mainly concerned with the adoption of the process model to be used for application development which are discused in great detail below. 6.4.1 Software Life Cycle Design Programming language design involves choosing features to be included in the language. Simplicity is essential. Machine independence improves the portability of a language. Specication A specication should be complete, concise, precise, correct, unambiguous, understandable, usable, and useful. Prototypes A quickly developed version of software which is probably incomplete or inecient. 6.4.2 Process Model The process model used for the development of the project is the Incremental Model . This model combines the elements of the linear sequential model with iterative philosophy of prototyping. The incremental model applies linear sequences in a staggered fashion as time progresses. Each linear sequence produce a deliverable increment for the software. The process ow for any increment can incorporate the prototyping model. When an incremental model is used, the rst increment is often a core product. Hence, basic requirements are met, but supplementary features remain undelivered. The 6.4. PROJECT MANAGEMENT
44
client uses the product. As a result of his evaluation, a plan is developed for the next increment. The plan addresses improvement of the core features and addition of supplementary features. The process is repeated following delivery of each increment, until the complete product is produced. As opposed to prototyping, incremental models focus on the delivery of an operational product after every iteration. 6.4.3 Team Members Contribution The project team under the guidance of Dr. Nitin S. Choubey consisted of 3 people. The following are the group members along with their responsibility.

6.4.3.1 Parth Bhalani

He possesses extraordinary skills in design and analysis of problems. His Software engineering skills were very useful in designing the project. All the Software engineering aspects of the project including scheduling of the project were handled by him.

6.4.3.2 Samarth Mittal

His main contributions included developing test cases for the application. He was mainly concerned with rigorous testing of individual modules developed and reporting bugs. The entire documentation also represents his tireless eorts.

6.4.3.3 Tanmaya Mahapatra

His main contributions included devlopment of complete API as well as working source code, plot scripts and installation scripts. Development of Makele to ease the process of compiling was made by him. 6.4.4 Project Schedule The entire schedule of how the project would be initiated and completed was developed using a tool called Gantt Project which helped us to schedule the project. For Gantt Chart refer to Figure 6.3
6.4. PROJECT MANAGEMENT
45
Figure 6.3: Gantt Chart for Project
6.4. PROJECT MANAGEMENT
CHAPTER 7
Project Implementation
Talk is cheap. Show me the code. Linus Torvalds
This chapter describes briey the major modules and the major functions of the application that has been implemented. We tried to be as precise as possible in giving references to the functions used from GLIBC 1 . We have also given pseudo-codes as well as ow chart wherever appropriate.
SECTION 7.1
Implemented Modules
The application in short consisted of 10 modules which are briey discussed below. The general architecture is that the application runs a single process intially but after setting up necessary environment for its use it starts forking child processes for dierent types of Scheduling. For example a child process is forked for FCFS Scheduling then that child processes rst intialises the necessary environment for its functioning and then it creates two threads for handling the two dierent process pools. This is same for every child process forked for SJN, Genetic, Round Robin Scheduling. After all these child processes with their respective threads nish the scheduling of process pools the nal plot values are nalised. Then the user is presented with a series of menu items displaying to plot graphs and other functionalities. In the event of a graph generation option another child process is forked and using exec family of System calls the request is passed to GNU Plot which
1
GNU Library for C.
46
CHAPTER 7. PROJECT IMPLEMENTATION
47
further proceeses the data and produces the appriopriate graphs in LaTeX, PNG and EPS format. 7.1.1 Main The Main module if the rst module invoked in the application. Its main job is to create a structure variable of type struct rlimit and use the setrlimit function dened in sys/resource.h to allow at maximum 70% CPU usage for this program as Genetic generations can sometimes eat away the Systems resources like hungry beasts. If the set is successful then it invokes the display menu() dened in application Module. PSeudo-Code 3 Main Module Pseudo-code M AX CP U U SAGE 70 Limiting CPU Usage to 70 % if set CP U = 0 then exit else display menu() end if
7.1.2 Application This module when called creates message queue for Inter-process communication. It also implements the UNIX reliable signal API for handling of signals like SIGINT, SIGXCPU and a user dened SIGUSR1. The user dened signal SIGUSR1 can be sent between any of the associated processes of the application. It is primarily used to inform the rceiver that a message is waiting for it in the Message queue. The structure variables for storing process details both for static as well as dynamic pools are created. The dynamic process details are generated randomly and static process details are read from the le. Then it forks 4 child processes to handle FCFS, SJN, Round Robin and Genetic Scheduling. After the child processes exit it displays a menu to plot graphs from the data collected. 7.1.3 Applog This module is quite peculiar in it implementation as well as usage. This module is basically used for logging purposes. It logs the main application events and other stu. Whenever a child process is forked or a thread is created this module is called to record those events to a log le. It also 7.1. IMPLEMENTED MODULES
48
records events like FCFS scheduling start and end time. The following code snippet shows its implementation.
1 int a p p l o g ( const char message ) 3 { time t curr time ; // f o r h o l d i n g c u r r e n t ti me 5 time t status ; // f o r h o l d i n g t h e s t a t u s o f ti me ( ) char a s c i i t i m e [ 2 6 ] ; // t h e b u f f e r f o r h o l d i n g a s c i i c o n v e r t e d ti me must be a t l e a s t 26 c h a r a c t e r s l o n g 7 int l o g f i l e f d ; // f o r h o l d i n g l o g f i l e d e s c r i p t o r int n bytes ; // f o r h o l d i n g number o f b y t e s w r i t t e n 9 mode t mode = S IRUSR | S IWUSR | S IRGRP | S IROTH ; // f o r s e t t i n g the log f i l e permission s t a t u s = time (& c u r r t i m e ) ; 11 i f ( s t a t u s == ( t i m e t ) 1 ) { 13 f p r i n t f ( stderr , %s : time f u n c t i o n f a i l e d t o f e t c h c u r r e n t k e r n e l time . \ n , 15 s t r e r r o r ( errno ) ) ; e x i t (EXIT SUCCESS) ; 17 } c t i m e r (& c u r r t i m e , a s c i i t i m e ) ; 19 l o g f i l e l o c k () ; l o g f i l e f d = open ( LOG FILE , O WRONLY | O APPEND, mode ) ; 21 i f ( l o g f i l e f d == 1) { 23 f p r i n t f ( s t d e r r , %s : Unable t o open l o g f i l e . \ n , s t r e r r o r ( errno ) ) ; } 25 n bytes = write ( l o g f i l e f d , ascii time , s t r l e n ( a s c i i t i m e ) ) ; i f ( n b y t e s == 1) 27 { f p r i n t f ( s t d e r r , %s : w r i t i n g t o l o g f i l e a t %s f a i l e d . \ n , 29 s t r e r r o r ( e r r n o ) , LOG FILE ) ; return ( 3 ) ; 31 } n b y t e s = w r i t e ( l o g f i l e f d , message , s t r l e n ( message ) ) ; 33 i f ( n b y t e s == 1) { 35 f p r i n t f ( s t d e r r , %s : w r i t i n g t o l o g f i l e a t %s f a i l e d . \ n , s t r e r r o r ( e r r n o ) , LOG FILE ) ; 37 return ( 3 ) ; } 39 i f ( ( f s y n c ( l o g f i l e f d ) ) == 1) f p r i n t f ( stderr , 41 %s : f s y n c ( ) f a i l e d t o sync I /O o p e r a t i o n s t o l o g f i l e a t %s \ n , s t r e r r o r ( e r r n o ) , LOG FILE ) ; 43 close ( lo g f ile f d ) ;
7.1. IMPLEMENTED MODULES

log file unlock () ; return (EXIT SUCCESS) ; }
49
45
Listing 7.1: Applog Module Implementation
7.1.4 File I/O This module does all the I/O involved with the application i.e writing log les, reading plot scripts and writing nal scheduled data etc. 7.1.5 Error Handler This module is registered with the help of atexit() 2 . This does all the necessary clean up stu so that the application can start normally next time. It closes all open sockets, pipes and removes all message queues created for IPC. It also removes all temporary les created and nally waits for any child process. After all child processes and threads have exited it hangs up the application. Its implementation is shown in Listing 7.2
#include a p i / e r r o r h a n d l e r . h 2 void 4 m s g g e t e r r o r h a n d l e r ( i n t mq id ) { 6 f p r i n t f ( s t d e r r , msget ( ) f u n c t i o n f a i l e d t o a l l o c a t e r e s o u r c e : %s \ n , s t r e r r o r ( errno ) ) ; 8 char msg [ 3 0 0 ] = msget ( ) f u n c t i o n f a i l e d t o a l l o c a t e r e s o u r c e :; s t r c a t ( msg , s t r e r r o r ( e r r n o ) ) ; 10 a p p l o g ( msg ) ; e x i t ( 1) ; 12 } 14 void m s g s n d e r r o r h a n d l e r ( i n t r e t v a l u e , i n t mq id ) 16 { f p r i n t f ( s t d e r r , msgsnd ( ) f u n c t i o n f a i l e d t o send message : %s \ n , 18 s t r e r r o r ( errno ) ) ; char msg [ 3 0 0 ] = msget ( ) f u n c t i o n f a i l e d t o send message : ; 20 s t r c a t ( msg , s t r e r r o r ( e r r n o ) ) ; a p p l o g ( msg ) ; 22 i p c r m ( mq id ) ; The atexit() function registers the given function to be called at normal process termination.
2

e x i t ( 1) ; 24 } 26 void e x i t h a n d l e r ( void ) 28 { p r i n t f ( Runnig E x i t Handler r o u t i n e . . P l e a s e Wait \ n ) ; 30 a p p l o g ( Runnig E x i t Handler r o u t i n e . . P l e a s e Wait \ n ) ; ipc rm ( exit mq id ) ; 32 int s t a t u s ; w a i t p i d ( 1 , &s t a t u s , 0 ) ; 34 check child status ( status ) ; a p p l o g ( \ n ) ; 36 exit (0) ; } 38 void 40 i p c r m ( i n t mq id ) { 42 m s g c t l ( mq id , IPC RMID , 0 ) ; } 44 void 46 c h e c k c h i l d s t a t u s ( i n t s t a t u s ) { 48 i f (WIFEXITED ( s t a t u s ) ) a p p l o g ( C h i l d p r o c e s s e x i t e d s u c c e s s f u l l y \ n ) ; 50 e l s e i f (WIFSIGNALED ( s t a t u s ) ) a p p l o g ( C h i l d t e r m i n a t e d with s i g n a l \ n ) ; 52 e l s e i f (WCOREDUMP ( s t a t u s ) ) a p p l o g ( A c o r e f i l e was w r i t t e n \ n ) ; 54 }
50
Listing 7.2: Error Handler Module Implementation
7.1.6 Scheduling This module serves as the core of all other scheduling modules. The parent process after forking several child processes for dierent types of scheduling actually invoke a part of this module which does the necessary environment setups and then aids the specic child process to create threads to continue with the scheduling process. The following snippet shows its partial implementation.
int 2 f c f s ( struct s t p r d e t a i l s s t d a t a , struct d y n a m i c p r o c e s s d e t a i l s dy data ) { 4 // s t w t l o c k = PTHREAD MUTEX INITIALIZER ; struct s t p r d e t a i l s s t s t a r t = s t d a t a ;

6 8 10 12 14
51
struct d y n a m i c p r o c e s s d e t a i l s d y s t a r t = d y d a t a ; p t h r e a d t s t f c f s t i d ; // s t o r e s t h r e a d i d pthread t d y f c f s t i d ; int r e t v a l s t f c f s ; // s t o r e s r e t u r n v a l u e o f p t h r e a d c r e a t e int r e t v a l d y f c f s ; // Threading from h e r e t o h a n d l e FCFS S c h e d u l i n g retval st fcfs = p t h r e a d c r e a t e (& s t f c f s t i d , NULL, s t f c f s , ( void ) st start ) ; retval dy fcfs = p t h r e a d c r e a t e (& d y f c f s t i d , NULL, d y f c f s , ( void ) dy start ) ; if (! retval st fcfs ) a p p l o g ( Thread Created S u c c e s s f u l l y f o r s t a t i c FCFS \ n ) ; else a p p l o g ( Thread c r e a t i o n f a i l e d f o r s t a t i c FCFS \ n ) ; if (! retval dy fcfs ) a p p l o g ( Thread Created S u c c e s s f u l l y f o r Dynamic FCFS \ n ) ; else a p p l o g ( Thread c r e a t i o n f a i l e d f o r Dynamic FCFS \ n ) ; / Wait t i l l t h r e a d s a r e c o m p l e t e b e f o r e main c o n t i n u e s . U n l e s s we / / w a i t we run t h e r i s k o f e x e c u t i n g an e x i t which w i l l terminate / / t h e p r o c e s s and a l l t h r e a d s b e f o r e t h e t h r e a d s have completed . / p t h r e a d j o i n ( s t f c f s t i d , NULL) ; p t h r e a d j o i n ( d y f c f s t i d , NULL) ; return (EXIT SUCCESS) ; }
16
18 20 22
24 26
28
30 32 34
Listing 7.3: partial Scheduling Module Implementation 7.1.7 FCFS This module reads the pool of processes and does the scheduling using the First come rst serve technique. It is relatively staright forward with no need to emphasize its internal implementation as well as working. 7.1.8 Round Robin This module reads the pool of processes and does the scheduling using the Round Robin technique. It denes a time quantum. Basing on this time 7.1. IMPLEMENTED MODULES
52
quantum a process is allowed to use the CPU and after that it is replaced with the next job in the queue. This process repeats till no other process are left in the queue. It is relatively staright forward. 7.1.9 SJN This module reads the pool of processes and does the scheduling using the Shortest Job Remaining Next technique. It searches the enitre queue of waiting jobs and selects the process with least CPU service time and allocates it to the CPU. It does this till all jobs have been scheduled.It is relatively staright forward with no need to emphasize its internal implementation as well as working. 7.1.10 Genetic This module is the most complicated of all the modules. For its intern working refer to Algorithm 5.1 & Pseudo-code 2
CHAPTER 8
Testing & Deployment

Debugging is twice as hard as writing the code in the rst place. Therefore, if you write the code as cleverly as possible, you are, by denition, not smart enough to debug it. Brian W. Kernighan
This chapter basically describes the test cases developed for the application to ensure its correctness and reliability and also documents its deployment.
SECTION 8.1
Testing
In computing, Software Testing is the branch of software engineering that deals with trying to show that a software behaves according to its intended specication. Each operation is to be tested by considering two aspects as below: The expected results. The actual results. The above two tests also represent the validity and invalidity tests. The valid tests are comprised of operations that the application performs without any errors/warnings. 53
CHAPTER 8. TESTING & DEPLOYMENT
54
The invalid tests are comprised of operations that the application performs with errors/warnings. Table 8.1 lists some of the test cases develoeped for the application.
SECTION 8.2
Deployment
The Application after rigorous Software testing was nally deployed on a Linux System with GNU Make & GCC installed. It was compiled using the make utility. The executable produced was made to rum to perform simulations. After the simulations the results obtained were critically observed to derive some conclusions. Figure 8.1 shows the application in running mode.
8
8.2. DEPLOYMENT
55
Figure 8.1: Running Application after Deployment
8
8.2. DEPLOYMENT
8.2. DEPLOYMENT
Table 8.1: Test Cases for Application Developed S/L No. 1. Module Application Module Operation Generate Expected Result Generate process details randomly & store them to les. Display the Menu-choosable UI to the user. Respawn the application for a new iteration to schedule a new pool of processes. Create threads for individual child processes for parallel scheduling of two process pools. Log all events like process forking, thread creation, thread termination etc. to a log le. Clean up Message queues and open le descriptors on error Actual Result Working as intended
2.
Application Module
Display UI
Working as intended
3.
Application Module
Respawn
Fails.
4.
Scheduling Module
Create Threads for Scheduling
Working as intended
5.
Applog Module
Log Events
Working as intended
6.
Error Handler Module
Clean up
Working as intended
Continued on next page 56
8.2. DEPLOYMENT
S/L No. 7.
Module File I/O Module
Table 8.1 continued from previous page Operation Expected Result Read & Write Handle all I/O requests made by any module. Schedule Read process details from pool & print scheduled data into a separate le Read process details from pool & print scheduled data into a separate le Read process details from pool & print scheduled data into a separate le Read process details from pool & print scheduled data into a separate le Read plot data from les & generate graphs, save them in PNG, EPS & LaTeX format
Actual Result Working as intended
8.
FCFS Module
Working as intended
9.
SJN Module
Schedule
Working as intended
10.
Genetic Module
Schedule
Working as intended
11.
Round Robin Module
Schedule
Working as intended
12.
Plotter Module
Plot graphs
Working as intended
57
CHAPTER 9
Simulation Results
Computer system analysis is like child-rearing; you can do grievous damage, but you cannot ensure success. Tom DeMarco
This chapter basically describes the simulation results obtained after the implemented application was successfully deployed. The Static and Dynamic Process Pools were randomly generated and they were Scheduled by various algorithms implemented namely FCFS, SJN, GA & Round Robin. The tables containing the process details and the graphs depicting the average turn around as well as waiting time are given. The arrival pattern of the randomly generated processes are also given for additional reference.
SECTION 9.1
Static Process Pool

The Static Process pool consists of 10 processes randomly generated. The Pool has been named as static because once the process details have been generated they are not subject to change of any kind. The Scheduling Modules of the application reads this pool of processes and schedules them. For randomly generated Process Data refer to Table 9.1 and for corresponding Arrival Pattern Graphs refer to Figure 9.1, 9.2, 9.3 & 9.4.
9
58
9.1. STATIC PROCESS POOL
CHAPTER 9. SIMULATION RESULTS
Table 9.1: Average Waiting Time & Turn Around Time of Processes - Static Process Pool. S/L No. 1. P1 5 P2 15 P3 12 P4 17 P5 7 P6 6 P7 9 P8 14 P9 18 P10 4 FCFS WT: 47.2 TAT: 57.9 SCJN WT: 34.2 TAT: 44.9 RR WT: 63.2 TAT: 74.0 GA WT: 34.2 TAT: 44.9
2.
36
72
10
79
21
86
49
46
74
36
WT: 234.5 TAT: 285.39
WT: 159.5 TAT: 210.39
WT: 318.29 TAT: 369.20
WT: 159.5 TAT: 210.39
59

SECTION 9.2
60
Dynamic Process Pool

The Dynamic Process pool consists of 10 processes randomly generated. This Pool is designed to tackle the dynamic nature of processes. By dynamic nature we mean that the process details once generated randomly can change at any moment. Because this kind of scenario is quite prevalent in real life scenario. The Scheduling Modules of the application reads this pool of processes and schedules them. But there is a small utility function that monitors this pool for any kind of dynamic changes and noties the Scheduling model of the changes. For randomly generated Process Data refer to Table 9.2, 9.3 and for corresponding Arrival Pattern Graphs refer to gures after them. 9.2.1 Graphs Explanation The Arrival Pattern of the processes of both the pools are plotted once in a log scale and other in a normal way. In the normal graphs we have use bezier & cspline approximations. The Bezier approximation is used because it approximates the data with a Bezier curve of degree n (the number of data points) that connects the endpoints while the cspline option connects consecutive points by natural cubic splines after rendering the data monotonic. These approximations help to increase the readability of the graphs and helps to correlate the arrival time of the randomly generated processes in a better way. The Log graph is used because if we increase the pool size of processes beyond 100 then the bezier approximation fails to give a good readable graph and the log graph comes as a rescue. The average waiting time & average turn around time of the processes in a pool are recorded and depicted using simple bar graphs which are quite easy to decipher. Only one iteration of Static Process Pool and ve iterations of Dynamic Process Pool are given. Every set begins with the arrival pattern graphs followed by comparison of wait time as well as turn around time. Further observations and remarks are made in Chapter 10.
9
9.2. DYNAMIC PROCESS POOL
Table 9.2: Average Waiting Time of Processes Dynamic Process pool - 5 Iterations S/L No. 1. P1 41 P2 57 P3 72 P4 41 P5 53 P6 93 P7 50 P8 60 P9 63 P10 73 FCFS 255.5 SCJN 229.6 RR 454.10 GA 229.6
2.
32
22
92
54
33
42
43
56
57
20
212.8
149.1
294.6
149.1
3.
46
62
45
94
75
26
95
94
89
50
330
237.5
469.6
237.5
4.
17
85
19
83
76
22
34
45
79
58
244.5
158.89
313.10
158.89
5.
74
14
37
28
29
67
84
86
49
02
220
131.3
258.89
131.39
61
Table 9.3: Average Turn Around Time of Processes Dynamic Process pool - 5 Iterations S/L No. 1. P1 41 P2 57 P3 72 P4 41 P5 53 P6 93 P7 50 P8 60 P9 63 P10 73 FCFS 315.79 SCJN 289.89 RR 514.40 GA 289.89
2.
32
22
92
54
33
42
43
56
57
20
257.89
194.19
339.70
194.19
3.
46
62
45
94
75
26
95
94
89
50
397.60
305.10
537.20
305.10
4.
17
85
19
83
76
22
34
45
79
58
296.29
210.69
364.89
210.69
5.
74
14
37
28
29
67
84
86
49
02
267.79
178.39
305.89
178.39
62
63
Static Process - Arrival Pattern 18 16 Arrival Time (seconds) 14 12 10 8 6 4 2 0 1 2 3 4 5 6 Process Name 7 8 9 10 cspline bezier
Figure 9.1: Static Process Pool - Process Arrival Pattern
Static Process Arrival Pattern 100 Log Graph
Arrival Time (seconds)
10
5 6 Process Name
10
Figure 9.2: Static Process Pool - Process Arrival Pattern(Log) 9.2. DYNAMIC PROCESS POOL
64
Static Process Pool - Comparison Graph 65 Average Waiting Time (seconds) 60 55 50 45 40 35 30 FCFS SCJN RR Scheduling Techniques SGA
Figure 9.3: Static Process Pool - Average Waiting Time
Static Process Pool - Comparison Graph Average Turn Around Time (seconds) 75 70 65 60 55 50 45 40 FCFS SCJN RR Scheduling Techniques SGA
Figure 9.4: Static Process Pool - Average Turn Around Time 9.2. DYNAMIC PROCESS POOL
65
Dynamic Process - Arrival Pattern 110 100 Arrival Time (seconds) 90 80 70 60 50 40 30 20 10 1 2 3 4 5 6 Process Name 7 8 9 10 cspline bezier
Figure 9.5: Dynamic Process Pool - Process Arrival Pattern - 1st Iteration Dynamic Process Arrival Pattern 100 Log Graph
Arrival Time (seconds) 10
5 6 Process Name
10
Figure 9.6: Dynamic Process Pool - Process Arrival Pattern(Log) 1st Iteration 9.2. DYNAMIC PROCESS POOL
66
Dynamic Process Pool - Comparison Graph 500 Average Waiting Time (seconds) 450 400 350 300 250 200
FCFS
SCJN RR Scheduling Techniques
SGA
Figure 9.7: Iteration
Dynamic Process Pool - Average Waiting Time - 1st
Dynamic Process Pool - Comparison Graph Average Turn Around Time (seconds) 550 500 450 400 350 300 250
FCFS
SGA
Figure 9.8: Dynamic Process Pool - Average Turn Around Time - 1st Iteration 9.2. DYNAMIC PROCESS POOL
67
Figure 9.9: Dynamic Process Pool - Process Arrival Pattern - 2nd Iteration Dynamic Process Arrival Pattern 100 Log Graph
10
5 6 Process Name
10
Figure 9.10: Dynamic Process Pool - Process Arrival Pattern(Log) - 2nd Iteration 9.2. DYNAMIC PROCESS POOL
68
Dynamic Process Pool - Comparison Graph 300 Average Waiting Time (seconds) 280 260 240 220 200 180 160 140 FCFS SCJN RR Scheduling Techniques SGA
Dynamic Process Pool - Average Waiting Time - 2nd
Dynamic Process Pool - Comparison Graph Average Turn Around Time (seconds) 340 320 300 280 260 240 220 200 180 FCFS SCJN RR Scheduling Techniques SGA
Figure 9.12: Dynamic Process Pool - Average Turn Around Time 2nd Iteration 9.2. DYNAMIC PROCESS POOL
69
Figure 9.13: Dynamic Process Pool - Process Arrival Pattern - 3rd Iteration Dynamic Process Arrival Pattern 100 Log Graph
10
5 6 Process Name
10
Figure 9.14: Dynamic Process Pool - Process Arrival Pattern(Log) - 3rd Iteration 9.2. DYNAMIC PROCESS POOL
70
Dynamic Process Pool - Comparison Graph 500 Average Waiting Time (seconds) 450 400 350 300 250 200
FCFS
SGA
Dynamic Process Pool - Average Waiting Time - 3rd
Dynamic Process Pool - Comparison Graph Average Turn Around Time (seconds) 550 500 450 400 350 300
FCFS
SGA
Figure 9.16: Dynamic Process Pool - Average Turn Around Time 3rd Iteration 9.2. DYNAMIC PROCESS POOL
71
Figure 9.17: Dynamic Process Pool - Process Arrival Pattern - 4th Iteration Dynamic Process Arrival Pattern 100 Log Graph
5 6 Process Name
10
Figure 9.18: Dynamic Process Pool - Process Arrival Pattern(Log) - 4th Iteration 9.2. DYNAMIC PROCESS POOL
72
Dynamic Process Pool - Comparison Graph 320 Average Waiting Time (seconds) 300 280 260 240 220 200 180 160 140 FCFS SCJN RR Scheduling Techniques SGA
Dynamic Process Pool - Average Waiting Time - 4th
Dynamic Process Pool - Comparison Graph Average Turn Around Time (seconds) 380 360 340 320 300 280 260 240 220 200 FCFS SCJN RR Scheduling Techniques SGA
Figure 9.20: Dynamic Process Pool - Average Turn Around Time 4th Iteration 9.2. DYNAMIC PROCESS POOL
73
Dynamic Process - Arrival Pattern 90 80 Arrival Time (seconds) 70 60 50 40 30 20 10 1 2 3 4 5 6 Process Name 7 8 9 10 cspline bezier
Figure 9.21: Dynamic Process Pool - Process Arrival Pattern - 5th Iteration Dynamic Process Arrival Pattern 100 Log Graph
5 6 Process Name
10
Figure 9.22: Dynamic Process Pool - Process Arrival Pattern(Log) - 5th Iteration 9.2. DYNAMIC PROCESS POOL
74
Dynamic Process Pool - Comparison Graph 260 Average Waiting Time (seconds) 240 220 200 180 160 140 120 FCFS SCJN RR Scheduling Techniques SGA
Dynamic Process Pool - Average Waiting Time - 5th
Dynamic Process Pool - Comparison Graph Average Turn Around Time (seconds) 320 300 280 260 240 220 200 180 160 FCFS SCJN RR Scheduling Techniques SGA
Figure 9.24: Dynamic Process Pool - Average Turn Around Time 5th Iteration 9.2. DYNAMIC PROCESS POOL
CHAPTER 10
Concluding Remarks
Beware of bugs in the above code; I have only proved it correct, not tried it. Donald Knuth
SECTION 10.1
Remarks
The simplicity of the methods used supports the assumption that GAs can provide a highly exible and user-friendly, near optimal solution to the general job sequencing problem. The genetic algorithms perform well to solve optimization problems. The experiment results clearly show that the proposed approach is able to nd optimized solution. The experiment carried out is ecient to nd best sequence. The GA module which we have used basically minimum waiting time of the processes to nd out the perfect job sequence. The GA module works correctly and gives the best result in comparison to other scheduling algorithms. But in doing so it behaved just like the SJN algorithm. The work can be extended in a way such that it gives the optimum results but does not mimic the SJN algorithm. This can be achieved by tampering the algorithm convergence criteria and the number of iterations for which the genetic generations are allowed to form. With these modications the algorithm would give near approximate results which can be used in real life scenarios. The performance can also be increased by applying diploidy operator on this problem.
75
10
Bibliography
[1] Candidate solutions, wikipedia. Candidate_solution/.
http://en.wikipedia.org/wiki/
[2] Pc magazine encyclopedia. http://www.pcmag.com/encyclopedia_term/ 0,2542,t=throughput&i=52868,00.asp. Accessed: 25/03/2012. [3] Wikipedia. http://wikipedia.org/. [4] Akbari, Z. A multilevel evolutionary algorithm for optimizing numerical functions. IJIEC 2 (2011), 419430. [5] Ashour, S. Sequencing theory. Springer - Verlag (1972). [6] Atique, M., and Ali, M. S. A novel adaptive neuro fuzzy inference system based cpu scheduler for multimedia operating system. In roceedings of International Joint Conference on Neural Networks (August 12-17, 2007). Orlando, Florida, USA. [7] Baker, J. E. Reducing bias and ineciency in the selection algorithm. In Proceedings of the Second International Conference on Genetic Algorithms and their Application (Hillsdale, New Jersey, USA, 1987), Lawrence Erlbaum Associates, pp. 1421. [8] Baker, K. R. Introduction to Sequencing and Scheduling. John Wiley and Sons Inc., New York, 1974. [9] Blazewicz, J., Domschke, W., and Pesch, E. The job shopscheduling problem: Conventional and new solution techniques. European Journal of Operational Research 93 (1996), 130. [10] Davis, L. Applying adaptive algorithms to epistactic domains. In Proceedings of the Inernational Joint Conference on Articial Intelligence (Los Angeles, USA, 1985), pp. 162164. [11] Eiben, A., et al. Genetic algorithms with multi-parent recombination. Proceedings of the International Conference on Evolutionary Computation PPSN III, ISBN 3-540-58484-6 (1994), 7887. The Third Conference on Parallel Problem Solving from Nature. 76
BIBLIOGRAPHY
77
[12] French, S. Sequencing and scheduling: An introduction to the mathematics of the job shop. Ellis Horwood, Chichester. [13] Goldberg, D. E. Genetic Algorithms in Search, Optimizations and Machine Learning. Addison-Wesley, 1989. [14] Harsora, V., and Shah, D. A. A modied genetic algorithm for process scheduling in distributed system. International Journal of Computer Applicatios (IJCA) IJCA Special Issue on Articial Intelligence Techniques - Novel Approaches & Practical Applications (2011). [15] Holland, J. H. Adaptations in Natural and Articial Systems. The University of Michigan press. [16] Hwanga, R., Gen, M., and Katayamaa, H. A performance evaluation of multiprocessor scheduling with genetic algorithm. Asia Pacic Management Review 11, 2 (2006), 6772. [17] Kumar, E. R., et al. Genetic algorithm approach to operating system process scheduling problem. International Journal of Engineering Science and Technology 2, 9 (2010), 42474252. [18] Madureira, A., Ramos, C., and do Carmo Silva, S. Using genetic algorithms for dynamic scheduling. [19] Nedunchelian, R., Koushik, K., Meiyappan, N., and V.Raghu. Dynamic task scheduling using parallel genetic algorithms for heterrogeneous distributed computing. [20] Nikravan, M., and Kashani, M. H. A genetic algorithm for process scheduling in distributed operating systems considering load balancing. In Proceedings of the 21st European Conference on Modelling and Simulation (2007), Ivan Zelinka, Zuzana Oplatkov a Alessandra Orsoni c ECMS. [21] Rahmani, A. M., and Rezvani, M. A novel genetic algorithm for static task scheduling in distributed systems. International Journal of Computer Theory and Engineering 1, 1 (April 2009), 17938201. [22] Schmitt, L. M. Fundamental study theory of genetic algorithms. International Journal of Modelling and Simulation Theoretical Computer Science 259 (2001), 161. [23] Silberschatz, A., Galvin, P. B., and Gagne, G. Operating System Principles, 7th ed. No. ISBN: 0471364142. John Wiley & Sons Inc., 2006. [24] Sindhwani, P., and Wadhwa, V. Genetic algorithm approach for optimal cpu scheduling. IJCST 2, 2 (June 2011). BIBLIOGRAPHY
BIBLIOGRAPHY
78
[25] Singh, A., Sevaux, M., and Rossi, A. A hybrid grouping genetic algorithm for multiprocessor scheduling. [26] Sivanandam, S. N., and Deepa, S. N. Introduction to genetic algorithms. [27] Tanenbaum, A. S. Modern Operating Systems, 2nd ed. Prentice Hall, 2009. [28] Ting, C.-K. On the mean convergence time of multi-parent genetic algorithms without selection. Advances in Articial Life, ISBN 978-3540-28848-0 (2005), 403412. [29] Vijayalakshmi, M. S. R., and Padmavathi, D. G. Performance study of ga and lsh in multiprocessor job scheduling. IJCSI - International Journal of Computer Science Issues (January 2010).
BIBLIOGRAPHY
APPENDIX A
Computational complexity
Computational complexity theory is a branch of the theory of computation in theoretical computer science and mathematics that focuses on classifying computational problems according to their inherent diculty, and relating those classes to each other. In this context, a computational problem is understood to be a task that is in principle amenable to being solved by a computer (which basically means that the problem can be stated by a set of mathematical instructions). Informally, a computational problem consists of problem instances and solutions to these problem instances. For example, primality testing is the problem of determining whether a given number is prime or not. The instances of this problem are natural numbers, and the solution to an instance is yes or no based on whether the number is prime or not. A problem is regarded as inherently dicult if its solution requires signicant resources, whatever the algorithm used. The theory formalizes this intuition, by introducing mathematical models of computation to study these problems and quantifying the amount of resources needed to solve them, such as time and storage. Other complexity measures are also used, such as the amount of communication (used in communication complexity), the number of gates in a circuit (used in circuit complexity) and the number of processors (used in parallel computing). One of the roles of computational complexity theory is to determine the practical limits on what computers can and cannot do.
SECTION A.1
P Complexity
It is one of the most fundamental complexity classes. It contains all decision problems which can be solved by a deterministic Turing machine using a polynomial amount of computation time, or polynomial time. Cobhams thesis holds that P is the class of computational problems which are e79
Appendix
APPENDIX A. COMPUTATIONAL COMPLEXITY
80
ciently solvable or tractable; in practice, some problems not known to be in P have practical solutions, and some that are in P do not, but this is a useful rule of thumb.
SECTION A.2
NP Complexity
NP is one of the most fundamental complexity classes. The abbreviation NP refers to nondeterministic polynomial time. Intuitively, NP is the set of all decision problems for which the instances where the answer is yes have eciently veriable proofs of the fact that the answer is indeed yes. More precisely, these proofs have to be veriable in polynomial time by a deterministic Turing machine. In an equivalent formal denition, NP is the set of decision problems where the yes-instances can be recognized in polynomial time by a non-deterministic Turing machine. The equivalence of the two denitions follows from the fact that an algorithm on such a nondeterministic machine consists of two phases, the rst of which consists of a guess about the solution which is generated in a non-deterministic way, while the second consists of a deterministic algorithm which veries or rejects the guess as a valid solution to the problem. The complexity class P is contained in NP, but NP contains many important problems, the hardest of which are called NP-complete problems, for which no polynomial-time algorithms are known for solving (not verifying) them. The most important open question in complexity theory, the P = NP problem, asks whether such algorithms actually exist for NP-complete, and by corollary, all NP problems. It is widely believed that this is not the case.
A.2. NP COMPLEXITY
Appendix
81
Figure A.1: Euler diagram for P, NP, NP-complete, and NP-hard set of problems
SECTION A.3
NP - Complete
In computational complexity theory, the complexity class NP-complete is a class of decision problems. A decision problem L is NP-complete if it is in the set of NP problems so that any given solution to the decision problem can be veried in polynomial time, and also in the set of NP-hard problems so that any NP problem can be converted into L by a transformation of the inputs in polynomial time. Although any given solution to such a problem can be veried quickly, there is no known ecient way to locate a solution in the rst place; indeed, the most notable characteristic of NP-complete problems is that no fast solution to them is known. That is, the time required to solve the problem using any currently known algorithm increases very quickly as the size of the problem grows. As a result, the time required to solve even moderately sized versions of many of these problems easily reaches into the billions or trillions of years, using any amount of computing power available today. As a consequence, determining whether or not it is possible to solve these problems quickly, called the P versus NP problem, is one of the principal unsolved problems in computer science today. While a method for computing the solutions to NP-complete problems using a reasonable amount of time remains undiscovered, computer scientists and programmers still frequently encounter NP-complete problems. NP-complete problems are often addressed by using approximation algorithms. A.3. NP - COMPLETE
Appendix

SECTION A.4
82
NP - Hard
NP-hard (non-deterministic polynomial-time hard), in computational complexity theory, is a class of problems that are, informally, at least as hard as the hardest problems in NP. A problem H is NP-hard if and only if there is an NP-complete problem L that is polynomial time Turing-reducible to H. In other words, L can be solved in polynomial time by an oracle machine with an oracle for H. Informally, we can think of an algorithm that can call such an oracle machine as a subroutine for solving H, and solves L in polynomial time, if the subroutine call takes only one step to compute. NP-hard problems may be of any type: decision problems, search problems, or optimization problems.
A.4. NP - HARD
Appendix
Index
Alleles, 32 Batch Processing Systems, 6 Candidate Solution, 10, 11 Chromosome, 10, 11, 32, 33 Colonization - Extinction, 12 CPU, 5, 6, 19, 3133, 47, 52 Crossover, 10, 12, 32, 33, 35 Cut and Splice, 13 Half Uniform Crossover, 13 Modied Crossover, 35 One-point Crossover, 13 Three Parent Crossover, 13 Two-point Crossover, 13 Uniform Crossover, 13 Deployment, 54 Evolutionary Algorithms, 9 Evolutionary Computation, 9 Feasible Set, 10 Feasible region, 10 Fitness Function, 11, 34 Fitness Value, 32 Initialization, 11 Inversion, 32, 35 inversion, 33 Kernel, 3 Migration, 12 Modules, 46 Application, 47 Applog, 47 Error Handler, 49 FCFS, 51 File I/O, 49 Main, 47 Round Robin, 51 SJN, 52 Mutation, 10, 15 Bit String Manipulation, 15 Boundary, 15 Flip Bit, 15 Non Uniform, 16 Uniform, 15 Networking, 4 NP Hard, 31
Operating System, 2 Gantt Chart, 44 Optimization, 32 Genes, 32 Genetic Algorithms, 9, 11, 16, 19, Probability, 32 3133, 75 Process Model, 43 Genetic Operator, 12, 32, 35 Incremental Model, 43 Genome, 15 Project Management, 43 Genotype, 33 Project Schedule, 44 Implementation, 46 Quantum, 51 83
INDEX Regrouping, 12 Replacement Strategy, 35 Reproduction, 12 Roulette Wheel selection, 13, 34 Scheduling, 5, 31 Dynamic, 5 FCFS Scheduling, 7 Lottery Scheduling, 8 Priority Scheduling, 8 Round Robin Scheduling, 7 SJN Scheduling, 8 Static, 5 Search Space, 10 Security, 4 Selection, 12, 34 Selection Function, 32 Shortest Job Next, 75 Simulation, 58 Graphs, 58 Results, 58 Tables, 58 Software Life Cycle, 43 Solution Space, 10 Symbols, 32 Team Members, 44 Termination, 16, 36 Testing, 53 Throughput, 31 TPS, 31 User Interface, 4
84
INDEX

Report Multiprocessor Scheduling Algorithm Implementation Using Genetic Algorithms

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Report Multiprocessor Scheduling Algorithm Implementation Using Genetic Algorithms

Uploaded by

Copyright:

Available Formats

Narsee Monjee Institute of Management Studies

Multiprocessor Scheduling Algorithm Implementation Using Genetic Algorithms

Authors: Tanmaya Mahapatra Parth Bhalani Samarth Mittal

Supervisor: Dr. Nitin S.Choubey

April 30, 2012

(Project Guide) Dr. N. S. Choubey

(Head of Dept.) Dr. N. S. Choubey

(Associate Dean) Dr. M.V. Deshpande

3.3.1 3.3.2 3.3.3

9.16 9.17 9.18 9.19 9.20 9.21 9.22 9.23 9.24

A.1 Euler Diagram . . . . . . . . . . . . . . . . . . . . . . . . . .

EP S Encapsulated PostScript F CF S First Come First Serve GA Genetic Algorithms

P DF Portable Document Format P N G Portable Network Graphics PS PostScript

SJN Shortest Job Next T P S Transactions Processed per Second

CHAPTER 2. PROCESS SCHEDULING

CHAPTER 2. PROCESS SCHEDULING

Process Scheduling Algorithms

2.2. PROCESS SCHEDULING ALGORITHMS

CHAPTER 2. PROCESS SCHEDULING Priority Scheduling

2.2. PROCESS SCHEDULING ALGORITHMS

CHAPTER 3. GENETIC ALGORITHMS Inheritance Mutation Crossover Selection

Candidate Solution & Chromosome

Also called as a genome

3.2. CANDIDATE SOLUTION & CHROMOSOME

CHAPTER 3. GENETIC ALGORITHMS

of the Problem Domain.

CHAPTER 3. GENETIC ALGORITHMS

Also called recombination

CHAPTER 3. GENETIC ALGORITHMS 3.3.3.1.1 Methods of selection of chromosomes for crossover

Also called as stochastic sampling with replacement.

CHAPTER 3. GENETIC ALGORITHMS

Figure 3.3: Two-point Crossover [3]

Figure 3.4: Cut and Splice [3]

CHAPTER 3. GENETIC ALGORITHMS

If the genome bit is 1,it is changed to 0 and vice versa

CHAPTER 3. GENETIC ALGORITHMS

CHAPTER 3. GENETIC ALGORITHMS

CHAPTER 3. GENETIC ALGORITHMS

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page 25

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

Continued on next page

CHAPTER 4. LITERATURE SURVEY

S/L No. 10.

Continued on next page

CHAPTER 4. LITERATURE SURVEY

S/L No. 11.

Process Scheduling Using GA

CHAPTER 5. PROCESS SCHEDULING USING GA