Programming in C: Assessed Practical Task, Jan. 2000

Programming in C: Assessed Practical Task, Jan. 2000

This assessed programming task is worth 15% of the credit CSM210 (Programming in C). In addition, a compulsory question worth no more than 40% will be set in the written test will make specific reference to the assessed practical Task.

Rules and Regulations

These are IMPORTANT. Please read them, and if in any doubt, seek clarification from me PRIOR to the submission of the assessed practical task.

Your programs MUST be compilable using the version of UNIX gcc installed on a UNIX server of the Department of Computer Science and AI. If the examiner is unable to compile the program on at least one of the UNIX servers provided by the Department of Computer Science and AI, the examiner will penalise the submission accordingly.

Plagiarism will not be tolerated. Students found to have plagiarised will fail the credit and will risk being expelled from their respective degree course. THIS IS FOR REAL.

The deadline for the assessed practical task will be 8:30 a.m. on the day of the credit test for CSM202. The task must be submitted to Room 202, New Computing Bulding, University of Malta, Tal-Qroqq, Msida, and must be signed in as proof of submission. Late submission of tasks will attract an immediate 50% penalty (regardless of the reason for lateness) with an additional 10% penalty for each subsequent day of late submission, weekends included. In the event that a candidate is sick on the day of the credit test, the candidate must ensure that the assessed practical task is delivered to the location specified above in conjunction with the medical certificate (which must arrive within 1 hour of the start of the exam). Please see the end of this document for the list of deliverable items. Note that the penalties referred to in this document apply only to the 15% allocated to the assessed practical task.

The examiner reserves the right to ask *any* candidate to defend his or her submission via an oral examination prior to the results being published for this credit.

Failing candidates: in the event of a resit, the marks awarded for the assessed practical task in the first sit will stand. Only the written part of the examination may be attempted again. The resit paper will contain a compulsory question, worth no more than 40%, directly relevant to the assessed practical task.

Description of the Assessed Practical Task

You are required to write a simple memory manager which meets the requirements specified in the remainder of this document.

A memory manager must satisfy requests for space, although the mechanism used to satisfy the request varies from strategy to strategy. Within an operating system context, requests for space typically originate from processes executing within the environment. Denying a process space in memory means that the process will be unable to continue executing. However, as space requirements are known only once processes make requests, it may be that there is, in fact, no space left in memory to satisfy the request. Memory management strategies typically decide what memory locations to allocate to requesting processes, and what to do in the event that there is not enough space in memory to immediately satisfy a request.

The memory manager which you will code is responsible for 10,000 blocks of memory (the physical size of each block is unimportant, but block numbers start from 0, so 10,000 blocks will occupy memory blocks 0 to 9,999 inclusive). The memory manager is to be designed to run for a variable amount of time. The life span of the memory manager is decided whenever the manager is initiated (i.e., each time the program is run), but is not to exceed 180 seconds real time. The duration is to be provided interactively by the user, and, if no duration is specified by the user, the duration is determined randomly by the program, which must inform the user of the decision. The memory manager loops until it shuts down when its life span limit is reached. Immediately prior to shutting down, the memory manager will provide some valuable statistics about the behaviour of processes and the manner in which memory was utilised.

At the start of each loop one of a number of events may occur:

  1. A request for space is received
  2. A request to free space is received
  3. A request to access a memory location is received

The events occur randomly.

Event A. A request for space is received

When a request for space is received then you are to assume that a new process has been created. The request for space will also indicate how much space, in blocks, is required. This can be simulated by randomly determining the number of blocks requested. If there are enough contiguous free blocks in memory, then the request can be granted. Otherwise the request is denied. If the request is granted, then you will need to maintain information about the process, for the life span of the process. A process is deemed to terminate when the memory manager receives a request to free space from the process occupying that space. The information about the process may then be discarded. The information you will maintain about a process during its life span will include

  1. a process id (an integer, allocated in ascending order starting from 0. It is essential that no two processes have the same id);
  2. the time of process creation (which can be synonymous with the time the request for space was received);
  3. the first block number allocated to the process;
  4. the total amount of space in blocks allocated to the process;
  5. all requests to access memory, made by this process, including whether the request is granted or denied (see Event C below).

If a request for space is denied, the process is deemed to have never existed. The memory manager will keep a record of the number of requests granted and denied.

There are a number of ways in which free space can be found. These are described in the section Locating free space below.

Event B. A request to free space is received

A request to free space may be received only from an existing process (identified by process id). When such a request is received, all the space allocated to the requesting process is freed, and all information about the process (e.g., its process id, etc) is removed. You are to assume that the process has terminated and consequently no longer exists.

Event C. A request to access a memory location is received

This type of request must originate from an existing process (identified by process id) and must refer to a memory location. For the purposes of this project, you are to assume that the reference is by block number from the first block in memory allocated to the process. For example, consider that a process has requested 10 blocks of space by event A. The memory manager has allocated 10 consecutive blocks starting from memory block number 500. This means that memory blocks 500 to 509 inclusive are allocated to the process. Consider now that the process requests to access block 15 by Event C. This should be interpreted as being the 16th block (given that block numbers start from 0) from the first block allocated to the process, i.e., block number 515. The memory manager will determine whether the process "owns" the block referred to. If it does the request is granted, otherwise it is denied. In the example given, the process does not own the corresponding block, so the request will be denied. All requests to access memory, together with the action taken, must be stored with the process information, as described in Event A above.

When the memory manager shuts down at the expiration of its life time, it forcibly terminates all existing processes, freeing the corresponding spaces in memory and deleting information about the existing processes.

Data collected by the memory manager

Sample logfile contents

Apart from the number of requests for space granted and denied (and percentage of requests denied), as described in Event A, the memory manager will also collect data regarding the number of access requests granted and denied. This data will be collected when a process terminates (either by Event B or forcibly by the memory manager itself prior to shutting down) and just before the process information is deleted. The information will be presented to the user running the memory manager just before the memory manager shuts down.

In addition, the memory manager will provide an activity log which records each event that occurs and the corresponding outcome. The activity log will be written to file.

The memory manager will also track the average percentage of free memory.

Locating free space

Three placement strategies are commonly used to locate free space. These are best fit, worst fit, and first fit. You are to implement all of them. Free space is commonly represented as a list of "holes" (unallocated memory), known as a free list. For each hole, the block number of the first block of the hole, and the number of free blocks in the hole are stored in the list. In order to satisfy a request for space the memory manager must identify a hole big enough to accommodate the space requested.

First fit

Holes are organised according to the order in which they occur from the beginning of memory. The first hole large enough to accommodate the process's request is allocated. After the request is granted a smaller hole may be left behind. This needs to be recorded.

Best fit

Holes are organised in the order of increasing size. The first hole large enough to accommodate the process's request is allocated. As with first fit, after the request is granted a smaller hole may be left behind. The free list will need to be updated to reflect it's location and size.

Worst Fit

Free space is organised in the order of decreasing size. The first hole large enough to accommodate the process's request is allocated. Once again, the free list will need to be updated.

The user will be prompted to choose which strategy to use when the memory manager is initiated.

Documentation.

The source code must be adequately commented to explain what each function does. In addition, the documention will describe how you solved and implemented the problem. Major data structures must be described, along with your reasons for choosing each data structure. Evidence that the program (and each placement strategy) works must be documented. Additionally, by comparing the results of several runs of each placement strategy, you are asked which placement strategy generally gives the best memory usage to space request satisfaction ratio. The ideal scenario is one where memory is constantly almost completely utilised and a low percentage of requests for space are denied. Evidence to support your opinion must be provided.

Assumptions

You may assume that a process never requests more than 10,000 blocks of memory, and that a process always requests at least one block.

To avoid processes making too many requests to access blocks which they do not own, rather than randomly selecting any of the 10,000 blocks, you may randomly select a block from the blocks reserved for the process plus 11% (rounded down to the nearest integer).

Deliverables

1. Electronic version of the C source code, which must be compilable by gcc on one of the department's UNIX servers. The source code should be adequately commented.

2. Electronic version of the C object code, which must have been generated by gcc on one of the department's UNIX servers.

3. Written documentation to include: