COMP30023代做、代写C/C++设计编程

项目预算：开发周期：发布时间：要求地区：

COMP30023: Computer Systems
Project 1: Process and Memory Management
Released: March 22, 2024
Due: 11:59 pm April 19, 2024 AEST
Weight: 15% of the final mark
1 Background
In this project, you will familiarise yourself with process scheduling and memory management.
You will simulate a process manager in a system where all processes are fully CPU-bound (i.e.,
have a single CPU burst and do no I/O). The process manager i) allocates processes to a CPU in
a round-robin manner and ii) supports contiguous, paged, and virtual memory management.
2 Process Manager Overview
The process manager runs in cycles. A cycle occurs after one quantum has elapsed. The process
manager has its own notion of time, referred to from here on as the simulation time. The simulation
time (TS) starts at 0 and increases by the length of the quantum (Q) every cycle. For this project,
Q will be an integer value between 1 and 3 (1 ≤ Q ≤ 3).
At the start of each cycle, the process manager must carry out the following tasks in sequence:
1. Identify all processes that have been submitted to the system since the last cycle occurred
and add them to the process queue in the order they appear in the process file. A process is
considered to have been submitted to the system if its arrival time is less than or equal to
the current simulation time Ts.
2. Identify whether the process (if any) that is currently running (i.e., was given CPU time in
the previous cycle) has completed its execution. If it has:
– The process’s state is updated (see Section 3)
– The process is removed from the process queue
– The process’s memory is deallocated
3. Determine the process that runs in this cycle. This decision is made based on the scheduling
algorithm (round robin) and the memory allocation strategy. This step entails:
– Updating the state of the process that is currently running (if any) and the state of the
newly allocated process (see Section 3)
– Updating the process queue if needed
A detailed explanation of this stage is given for each task.
4. Increment the simulation time by Q seconds.
This cycle is repeated iteratively until all the processes that were submitted to the system have
completed their execution.
1
3 Process Lifecycle
The lifecycle of a process is as follows:
1. A process is submitted to the process manager via an input file (See Section 6 for more
details). Note that you may read all the processes in the input file into a data structure, and
use said data structure to determine which processes should be added to the process queue
based on their arrival time and the current simulation time.
2. A process is in a READY state after it has arrived (arrival time less than or equal to
the simulation time). READY processes are considered by the scheduling algorithm as
candidates to be allocated to the CPU.
3. The process that has been selected to use the CPU enters a RUNNING state.
4. After running for one quantum,
– If the process has completed its execution, the process is terminated and moves to the
FINISHED state.
– If the process requires more CPU time and there are other READY processes, the
process transitions back to the READY state to await more CPU time.
– If the process requires more CPU time and there are no other READY processes, the
process remains in the RUNNING state and runs for another quantum.
For simplicity, a process can only transition to the FINISHED state at the end of a quantum.
This means that, in cases in which the service time of a process is not a multiple of the
quantum, the total amount of time the process spends in the RUNNING state will be greater
than its service time.
4 Process Scheduling
In this section, you will focus on implementing the scheduling logic of the process manager. For
this purpose, you will assume infinite memory that requires no management.
4.1 Task 1: Round-Robin Scheduling with Infinite Memory
In this task, you will implement a round-robin scheduler under the assumption that the memory
requirements of processes are immediately satisfied upon arrival. This will allow you to focus
on implementing the scheduling logic before moving on to implementing memory management
approaches in subsequent tasks.
In round-robin scheduling, processes execute on the CPU one quantum at a time. The scheduler
allocates the CPU to the process at the head of the process queue (i.e., the process enters the
RUNNING state). After one quantum has elapsed, the process returns to the READY state,
moves to the tail of the process queue, and the CPU is allocated to the next process in the queue
(i.e., the new head of the queue).
There are two special cases in which a process does not transition from RUNNING to READY at
the end of a quantum (as defined in Section 3):
1. There are no other processes in the queue, and the process requires more CPU time. The
process remains in a RUNNING state and continues to use the CPU for another quantum.
2. The process completed its execution. The process transitions to the FINISHED state and is
removed from the process queue.
Note that, based on the order in which the process manager performs tasks (Section 2), a process
that has exhausted its quantum is placed at the tail of the process queue after newly arrived
processes have been inserted into said queue.
2
5 Memory Management
For the tasks in this section, you will assume memory is finite. Memory must be allocated to a
process before said process is able to run on the CPU. Consequently, a process’s memory must be
deallocated upon completion of said process.
To accomplish this, you will extend the round-robin scheduler implemented in Task 1 to consider
the memory requirements of a process before it is able to enter the RUNNING state. When it is a
process’ turn to execute (as determined by the round-robin algorithm), the process manager must
first allocate memory to the process by following one of the following strategies:
• Allocating a contiguous block of memory (Task 2)
• Allocating all the pages of the process to frames in memory (Task 3)
• Allocating a subset of the pages of the process to frames in memory (Task 4)
Only if, and after, memory allocation is successful is a process allowed to use the CPU for the
corresponding quantum.
5.1 Task 2: Round-Robin Scheduling with Contiguous Memory Allocation
In this task, the process manager allocates a process’s memory in its entirety (i.e., there is no
paging) and in a contiguous block. Memory must be allocated following the First Fit memory
allocation algorithm1 as explained in the textbook and the lectures. The memory remains allocated
for the duration of the process’s runtime (i.e., there is no swapping).
A process for which memory allocation cannot be currently met should remain in a READY state,
and be moved from the head to the tail of the process queue. Within the same cycle, the scheduler
must continue to iterate over the process queue until it finds a process that can execute (i.e.,
memory has been allocated). Note that it is only after a process has successfully transitioned from
READY to RUNNING or when the process queue is empty that the process manager moves on
to the next cycle, and hence, the next quantum.
Important Notes:
• The memory capacity of the simulated computer is static. For this project, you will assume
a total of 2048 KB is available to allocate to user processes.
• The memory requirement (in KB) of each process is known in advance and is static, i.e., the
amount of memory a process is allocated remains constant throughout its execution.
• For simplicity, you will assume memory is addressed in blocks of 1 KB. Memory addresses
in the system are therefore in the range [0..2048).
• When allocating a memory block, always allocate the block starting at the lowest memory
address of a memory hole. For example, a block of 10 KB needs to be allocated. The
identified memory hole (according to first-fit) is [10..30]. The memory block should then be
allocated to addresses [10..19].
• Once a process terminates, its memory must be freed and merged into any adjacent holes if
they exist.
A sample execution flow, as specified by this task, would be as follows:
1. The round-robin scheduler determines process p is the next process to be allocated to the
CPU.
2. Before allocating the process to the CPU, the process manager checks whether p has been
allocated memory.
1Hint: The First Fit algorithm selects the first available contiguous block of memory that is large enough to
accommodate the memory requirement of a process.
3
(a) If p’s memory has already been allocated, p gets to use the CPU for the corresponding
quantum.
(b) If p’s memory has not been allocated, the process manager attempts to allocate a contiguous block.
i. If successful, p gets to use the CPU for the corresponding quantum.
ii. If the allocation is unsuccessful (i.e., there is no sufficient memory in the system at
this time), p does not execute, remains in a READY state, and is moved to the
tail of the process queue. The scheduler looks for another process to execute by
returning to step 1.
5.2 Task 3: Round-Robin Scheduling with Paged Memory Allocation
This task assumes a paged memory system with swapping. The memory required by a process is
divided into pages, and physical memory is divided into frames. Pages that are mapped to frames
in memory are considered to be allocated.
Before a process runs on the CPU, all of its pages must be allocated to frames in memory. If there
are not enough empty frames to fit a process’s pages, then pages of another process or processes
need to be swapped to disk to make space for the process. When choosing a process to swap, you
must choose the process that was least recently executed among other processes (excluding the
current one) and evict all of its pages. If there is still not enough space, continue evicting all
pages of other processes following the least-recently executed policy until there is sufficient space.
Important Notes:
• You will assume a total of 2048 KB is available to allocate to user processes.
• The memory requirement of each process (in KB) is known in advance and is static, i.e.,
the amount of memory a process requires, and hence the number of pages, remains constant
throughout its execution.
• Once a process terminates, all of its pages must be evicted from memory (i.e., deallocated).
• The size of pages and frames is 4 KB.
• Each frame is numbered, starting from 0 and increasing by 1. For the assumed memory size
of 2048 KB, there are 512 pages in total, with page numbers from 0 to 511.
• Pages should be allocated to frames in increasing frame number. For example, if a process
requires 3 pages to be allocated, and frames 0, 1, 5, 8, and 9, are free (or were freed via
swapping). The process pages must be mapped to frames 0, 1, and 5.
A sample execution flow, as specified by this task, would be as follows:
1. The round-robin scheduler determines process p is the next process to be allocated to the
CPU.
2. Before allocating the process to the CPU, the process manager checks whether p’s pages are
allocated in memory.
(a) If p’s pages are allocated, p uses the CPU for the corresponding quantum.
(b) If p’s pages have not been allocated and there are not enough free frames in memory, the
process manager evicts the pages of one or more processes following the least-recently
executed policy.
(c) Once there are sufficient free frames in memory, the process manager allocates p’s pages
and p runs on the CPU for the corresponding quantum.
4
5.3 Task 4: Round-Robin Scheduling with Virtual Memory Allocation
This task will assume a paged system with swapping similar to that in Task 3. However, we will
now consider the case of virtual memory providing the illusion of a larger-than-available memory
to processes.
You will now assume that a process does not need all pages to be allocated before it is allowed to
execute. In this task, a process can be executed if at least 4 of its pages are allocated (or all pages
in case of processes requiring less than 4 pages). If there are more than 4 frames available at the
time of allocation(or reallocation), the process manager must allocate as many pages as possible.
For example, if a process requires 7 pages and there are 6 frames available, the process manager
must allocate 6 of the 7 pages to the available frames. If a process requires 7 pages and there are
10 frames available, the process manager must allocate all 7 pages to the free frames.
Similar to swapping, if there are not enough empty frames for the process that is scheduled to be
executed, pages of the least recently executed process need to be evicted one at a time until there
are 4 empty pages (or less if the process requires less than 4 pages). The lowest numbered frames
belonging to the least recently executed process must be evicted first. For example, if the least
recently executed process was allocated frames 1,5,7,9, and 2 frames need to be evicted, frames
1,5 must be evicted. This is in contrast to Task 3, where all pages of the least recently executed
process would be evicted.
Important Notes:
• You will assume a total of 2048 KB is available to allocate to user processes.
• Once a process terminates, any allocated pages must be evicted from memory (i.e., deallocated).
• The size of pages and frames is 4 KB.
• Each frame is numbered, starting from 0 and increasing by 1. For the assumed memory size
of 2048 KB, there are 512 pages in total, with page numbers from 0 to 511.
• Pages should be allocated to frames in increasing frame number. For example, if a process
requires 3 pages to be allocated, and frames 0, 1, 5, 8, and 9, are free (or were freed via
swapping). The process pages must be mapped to frames 0, 1, and 5.
A sample execution flow, as specified by this task, would be as follows:
1. The round-robin scheduler determines process p, requiring n pages, is the next process to be
allocated to the CPU.
2. Before allocating the process to the CPU, the process manager checks whether p has at least
4 (n ≥ 4) or all (n < 4) pages allocated.
(a) If p’s page allocation requirements are met, p uses the CPU for the corresponding
quantum.
(b) If p’s page allocation requirements are not met and there are not enough free frames
in memory, the process manager evicts just enough pages to meet the page allocation
requirements of p following the least-recently executed policy.
(c) Once there are sufficient free frames in memory, the process manager allocates p’s pages
and p runs on the CPU for the corresponding quantum.
6 Program Specification
Your program must be called allocate and take the following command line arguments. The
arguments can be passed in any order but you can assume that all the arguments will be passed
correctly, and each argument will be passed exactly once.
Usage: allocate -f -m (infinite | first-fit | paged | virtual) -q (1 | 2 | 3)
-f filename will specify a valid relative or absolute path to the input file describing the processes.
5
-m memory-strategy where memory-strategy is one of {infinite, first-fit, paged, virtual}.
-q quantum where quantum is one of {1, 2, 3}.
The input file, filename, contains the list of processes to be executed, with each line containing a
process. Each process is represented by a single space-separated tuple (time-arrived, process-name,
service-time, memory-requirement).
You can assume:
• The file will be sorted by time-arrived which is an integer in [0, 2
32) indicating seconds.
• All process-names will be distinct uppercase alphanumeric strings of minimum length 1 and
maximum length 8.
• The first process will always have time-arrived set to 0.
• service-time will be an integer in [1, 2
32) indicating seconds.
• memory-requirement will be an integer in [1, 2048] indicating KBs of memory required.
• The file is space delimited, and each line (including the last) will be terminated with an LF
(ASCII 0x0a) control character.
• Simulation time will be an integer in [0, 2
32) indicating seconds.
Note that no assumptions may be made about the number of processes in the input file and that
there can be input files with large gaps in the process arrival time. You can, however, assume
that the input files we will use to test your program are such that simulations will complete in a
reasonable amount of time.
In addition, no assumptions may be made about the length of the file name (filename).
You can read the whole file before starting the simulation or read one line at a time.
We will not give malformed input (e.g., negative memory requirement or more than 4 columns in
the process description file). If you want to reject malformed command line arguments or input,
your program should exit with a non-zero exit code per convention.
Example: ./allocate -f processes.txt -m infinite -q 3.
The allocate program is required to simulate the execution of processes in the file processes.txt
using the round-robin scheduling algorithm and the infinite memory strategy with a quantum of 3
seconds.
Given processes.txt with the following information:
0 P4 30 16
29 P2 40 64
99 P1 20 32
The program should simulate the execution of 3 processes where process P4 arrives at time 0,
needs 30 seconds of CPU time to finish, and requires 16 KB of memory; process P2 arrives at time
29, needs 40 seconds of time to complete and requires 64 KB of memory, etc.
7 Expected Output
In order for us to verify that your code meets the above specification, it should print to standard
output (stderr will be ignored) information regarding the states of the system and statistics of
its performance. All times are to be printed in seconds.
6
7.1 Execution transcript
For the following events, the code should print out a line in the following format:
• When a process runs on the CPU (this includes the first time and every time it resumes its
execution):
,RUNNING,process-name=,remaining-time=,
mem-usage=%,allocated-at=,mem-frames=[]
where:
– ‘time’ refers to the simulation time at which CPU is given to the process;
– ‘pname’ refers to the name of the process as specified in the process file;
– ‘rtime’ refers to the remaining execution time for this process;
– ‘musage’ is a (rounded up) integer referring to the percentage of memory currently
occupied by all processes, after pname has been allocated memory;
– ‘addr’ is the memory address (between [0, 2048)) at which the memory allocation for
pname starts at;
– ‘frames’ is a list of frame numbers (given in increasing order) that are allocated to the
current process, separated by commas.
In the case of infinite memory (Task 1, -m infinite), your program should not print
out any information about memory allocation or usage. That is, mem-usage, allocated-at,
and mem-frames should not be printed.
An example of the simplified output would be:
20,RUNNING,process-name=P4,remaining-time=10
In the case of first-fit (Task 2, -m first-fit), your program should not print out the
set of allocated frames. That is, mem-frames should not be printed.
An example of the simplified output would be:
20,RUNNING,process-name=P4,remaining-time=10,mem-usage=50%,allocated-at=10
In the case of paged (Task 3, -m paged) and virtual memory(Task 4, -m virtual),
your program should not print out the memory allocation address. That is, allocated-at
should not be printed.
An example of the simplified output would be:
20,RUNNING,process-name=P4,remaining-time=10,mem-usage=50%,mem-frames=[0,1,2]
• In the case of paged (Task 3, -m paged) and virtual memory (Task 4, -m virtual), every
time pages are deallocated from memory:
,EVICTED,evicted-frames=<[frames]>
where:
– ‘time’ is as above for the RUNNING event;
– ‘frames’ refers to the list of frame numbers (given in increasing order), separated by
commas, that were freed.
In cases in which pages of more than one process are evicted, Only one EVICTED event
should be printed. This means your program should never print two EVICTED events in two
consecutive lines.
In the cases of infinite memory (Task 1, -m infinite) and first-fit (Task 2, -m
first-fit), no EVICTED events should be printed.
• Every time a process finishes:
,FINISHED,process-name=,proc-remaining=
7
where:
– ‘time’ is the simulation time at which the process transitions to the FINISHED state;
– ‘pname’ refers to the name of the process as specified in the process file;
– ‘pleft’ refers to the number of processes that are waiting to be executed.
i.e. The number of processes that are in the process queue when this particular process
terminates.
Note that EVICTED and FINISHED events do not incur time. Hence, lines following these event lines
may begin with the same ‘’. If the eviction resulted due to process completion, EVICTED
line precedes FINISHED.
7.2 Task 5: Performance Statistics
When the simulation completes, three lines with the following performance statistics about your
simulation performance should be printed:
• Turnaround time: average turnaround time (in seconds, rounded up to an integer) for
all processes in the simulation. Recall the turnaround time is the time elapsed between the
arrival and the completion of a process.
• Time overhead: maximum and average time overhead, both rounded to the first two
decimal points. The time overhead of a process is defined as its turnaround time divided by
its service time.
• Makespan: The length of the simulation. That is, simulation time when all processes in
the input completed their execution.
Example:
Turnaround time 31
Time overhead 1.03 1.02
Makespan 119
8 Marking Criteria
The marks are broken down as follows:
Task Marks
Task 1: Round-robin + infinite memory (Section 5) 3
Task 2: Round-robin + first-fit (Section 5.1) 3
Task 3: Round-robin + paged memory (Section 5.2) 3
Task 4: Round-robin + virtual memory (Section 5.3) 3
Task 5: Performance statistics (Section 7.2) 1
Build quality 1
Quality of software practices 1
TOTAL 15
Assessment of Tasks 1-5 Tasks 1, 2, 3, 4, and 5 will be assessed through automated testing.
We will compile your code and run it against a set of test cases. We will compare the output
produced by your program against the expected output of each test case. This is why it is essential
that you follow the specification and produce output exactly as outlined in Section 7.1.
You will be given access to a subset of the test cases used to assess your project as well as their
expected outputs. Half of the marks for Tasks 1-5 will be awarded based on this subset of visible
test cases. The other half of the marks will be determined based on a different subset of hidden
test cases not available to you.
Because we compile and run your code, it is a requirement that your code compiles and runs
on the provided VMs and produces deterministic output. Code that does not meet these
requirements cannot be assessed and hence will receive 0 marks (at least) for Tasks 1 - 5.
8
Build quality
• The repository must contain a Makefile that produces an executable named “allocate”,
along with all source files required to compile the executable. Place the Makefile at the root
of your repository, and ensure that running make places the executable there too.
• Make sure that all source code is committed and pushed.
• Running make clean && make -B && ./allocate <...arguments> should execute the submission.
• Compiling using “-Wall” should yield no warnings.
• Running make clean should remove all object code and executables.
• Do not commit allocate or other executable files (see Practical 1). Scripts (with .sh
extension) are exempted.
• The automated test script expects allocate to exit with status code 0 (i.e. it successfully
runs and terminates).
The mark calculated for “Build quality” will be visible on CI (see Section 10).
Quality of software practices Factors considered include:
• Proper use of version control, based on the regularity of commit and push events, their
content and associated commit messages (e.g., repositories with a single commit and/or noninformative commit messages will lose 0.5 marks).
• Quality of code, based on the choice of variable names, comments, formatting (e.g. consistent indentation and spacing), and structure (e.g. abstraction, modularity).
• Proper memory management, based on the absence of memory errors and memory leaks.
Further deductions may be applied to inappropriate submissions, e.g. catching segmentation faults,
hard-coding the output into the code.
9 Submission
Programming language All code must be written in C (e.g., it should not be a C-wrapper
over non C-code).
Use of libraries Your code will likely rely on data structures to manage processes and memory.
You may write your own code, reuse any existing code you might have written (e.g., in other
subjects), or use external libraries for this (and only this) purpose. External libraries cannot be
used in your project for any other purpose.
Provide attribution in references.txt, and a copy (of the original versions) of both reused and
external code in your submission, under an ext/ subdirectory. Code which we have provided on
the LMS of this subject is exempt.
You may use standard libraries (e.g. to read files, sort, parse command line arguments2
etc.).
GitHub The use of GitHub is mandatory. Your submission will be assessed based using the code
in your Project 1 repository (proj1-〈usernames...〉) under the subject’s organization.
We strongly encourage you to commit your code at least once per day. Be sure to push after
you commit. This is important not only to maintain a backup of your code, but also because the
git history may be considered for matters such as special consideration, extensions and potential
plagiarism. Proper use of git will have a positive effect on the mark you get for quality of software
practices.
2https://www.gnu.org/software/libc/manual/html_node/Getopt.html
9
Submission To submit your project, please follow these steps carefully:
1. Push your code to the repository named proj1-〈usernames...〉 under the subject’s organization, https://github.com/feit-comp30023-2024.
Executable files (that is, all files with the executable bit that are in your repository) will be
removed before marking. Hence, ensure that none of your source files have the executable
bit.
Ensure your code compiles and runs on the provided VMs. Code that does not compile
or produce correct output on VMs will typically receive very low or 0 marks.
2. Submit the full 40-digit SHA1 hash of the commit you want us to mark to the Project
1 Assignment on the LMS.
You are allowed to update your chosen commit by resubmitting the LMS assignment as
many times as desired. However, only the last commit hash submitted to the LMS before
the deadline (or approved extension) will be marked without a late penalty.
3. Ensure that the commit that you submitted to the LMS is correct and accessible from a fresh
clone of your repository. An example of how to do this is as follows:
git clone git@github.com:feit-comp30023-2024/proj1- proj1
cd proj1
git checkout
Please be aware that we will only mark the commit submitted via the LMS. It is your
responsibility to ensure that the submission is correct and corresponds to the commit you
want us to mark.
Late submissions Late submissions will incur a deduction of 2 marks per day (or part thereof).
For example, a submission made 1 hour after the deadline is considered to be 1 day late and carries
a deduction of 2 marks.
We strongly encourage you to allow sufficient time to follow the submission process outlined above.
Leaving it to the last minute usually results in a submission that is a few minutes to a few hours
late, or in the submission of the incorrect commit hash. Either case leads to late penalties.
The submission date is determined solely by the date in which the LMS assignment was submitted.
Forgetting to submit via the LMS or submitting the wrong commit hash will result in a late penalty
that will apply regardless of the commit date.
We will not give partial marks or allow code edits for either known or hidden cases without applying
a late penalty (calculated from the deadline).
Extension policy: If you believe you have a valid reason to require an extension, please fill in
the Project 1 extension request form available on the LMS at the earliest opportunity, which in
most instances should be well before the submission deadline. Extensions will not be considered
otherwise. Requests for extensions are not automatic and are considered on a case-by-case basis.
You are required to submit supporting evidence such as a medical certificate. In addition, your
git log file should illustrate the progress made on the project up to the date of your request.
10 Testing
You will be given access to several test cases and their expected outputs. However, these test cases
are not exhaustive and will not cover all edge cases. Please be aware that the test suite (visible
and hidden cases combined) will aim to cover all of the business rules which are written in the
specification. Hidden test cases will also be more difficult. Hence, you are strongly encouraged
to write tests to verify the correctness of your own implementation.
Testing Locally: You can clone the sample test cases to test locally, from:
feit-comp30023-2024/project1.
10
Continuous Integration Testing: To provide you with feedback on your progress before the
deadline, we have set up a Continuous Integration (CI) pipeline on GitHub with the same set of
test cases.
Though you are strongly encouraged to use this service, the usage of CI is not assessed, i.e., we do
not require CI tasks to complete for a submission to be considered for marking.
The requisite ci.yml file has been provisioned and placed in your repository, but is also available
from the .github/workflows directory of the project1 repository linked above.
11 Team Work
Both team members are expected to contribute equally to the project. If this is not the case,
please approach the head tutor or lecturer to discuss your situation. In cases in which a student’s
contribution is deemed inadequate, the student’s mark for the project will be adjusted to reflect
their lack of contribution. We will look at git logs when making such an assessment.
12 Collaboration and Plagiarism
You may discuss this project abstractly with your classmates but what gets typed as part of your
program must be your and your teammate’s work.
You cannot copy work from another another student or team. Do not share your code and do not
ask others to give you their programs. Do not post your code on the subject’s discussion board
Ed. The best way to help your friends in this regard is to say a very firm “no” if they ask to see
your program. See https://academicintegrity.unimelb.edu.au for more information.
Note that soliciting solutions via posts to online forums, whether or not there is payment involved,
is also Academic Misconduct. You should not post your code to any public location while the
assignment is underway or prior to the release of the assignment marks.
If you use any code that was not written by you or your teammate, you must attribute that code to
the source you got it from (e.g., a book, Stack Exchange, ChatGPT). Include a references.txt
file in the root directory of your submission if you require attributing any code.
11