Reference no: EM133115080

COMP 3430 Operating Systems - University of Manitoba

In assignment, you're going to implement scheduling policies, and write programs that use threads, locks, and condition variables.

You're going to do this by simulating running tasks on a multi-CPU system with threads.

Create a MLFQ scheduling using multi threading in C language

Simulating Scheduling

In this question, you'll be writing a simulator that:

Implements a MLFQ scheduling policies
Simulates the behaviour of scheduling on a multi CPU system using threads (where each "CPU" is one thread)

You will also be comparing the performance of different scheduling policies using this simulator.

Your simulator will implement a Multi-level feedback queue (preemptive, priority-based) with tasks that enter the system at start time, and while the simulator is running.

1. Before the simulator starts, you will load the workload (your set of tasks) into the scheduler, and initialize all of your "CPU" threads. The "CPU" threads should wait after they have been initialized until the dispatcher notifies them that tasks are available. A "reading" thread will sleep, "waiting" for the next batch of processes to enter the system.

2. When the simulator starts, your scheduling policy will decide which task should be executed next given the complete set of tasks that are waiting to run.

3. The dispatcher will notify all waiting "CPU" threads that a new task is available to be executed. One of the "CPU" threads will take the task and "run" it.

4. The "CPU" threads will each run one task at a time. Running a task here means doing two things: Deciding if/when the task will make a system call (i.e., request I/O) and sleeping until either the task is done, the time slice is complete, or the time until the task makes a system call elapses.

Once sleeping is done, your "CPU" should update the appropriate accounting values for the task before placing the task back into the queue or into the done area.

5. If a task still has time left to complete, it will be sent back to the scheduling policy to be rescheduled. Note that when the task is rescheduled, it may or may not be "run" on the same CPU again (we're not implementing processor
affinity).

6. If a task does not have any time left to complete after running on the CPU, the CPU will put the task into the "Done" area.

7. When there are no tasks left to be scheduled (NOTE: this is not the same as just no tasks in the scheduler, this is the condition that there are no tasks in the scheduler and the "reading" thread has finished reading all tasks from the file), the simulator shuts down and produces a report.

8. When the "reading" thread wakes, it resumes reading the processes file, adding tasks to the system until the file end, or another delay is found.

If you implement your scheduler using this architecture, your implementation will require several locks, minimally where the "reader" thread adds tasks to the ready queue, where the CPUs get a task from the dispatcher, where the CPUs return the task to the running queue, and where the CPUs write tasks into the "Done" area. The level of granularity that you choose to implement in terms of locking the queue here is your decision.

Queues

You are welcome to implement your own queue(s) as a linked data structure in C, but you also have other options:

1. Use the queue wrapper library defined in sys/queue.h (see man queue).

2. Use a "ticket-based" queuing/priority system, similar to the ticket lock implementation described in Chapter 28 of OSTEP.

3. Use an array/some arrays and constantly sort them by some property of each task.

You should be submitting at least the following files:

A Makefile.
A README.md that includes a summary of how to compile and run your programs (compiling should be "run make", but you should explicitly tell the grader how to run your program, e.g., what arguments to pass to the program

on the command line), and your report on the performance of your scheduler. Your solution for question 1 (probably just 1 .c file, but maybe more).
The sample workload that's different from the provided workload that you used to test your implementation.

Attachment:- Operating Systems.rar