Programming Assignment 3

Transcription

1 UNIVERSITY OF NEBRASKA AT OMAHA Computer Science 4500/8506 Operating Systems Spring 2016 Programming Assignment 3 Introduction For this programming assignment you are to write a C, C++, Java, or Python program that demonstrates the processing of memory allocation and deallocation requests when the first fit algorithm is being used. The input data (which is to be read from the standard input) will begin with a single positive integer called MSIZE. This is the size of the simulated memory that will be used to satisfy allocation requests. You should assume the memory region extends from memory location 0 through memory location MSIZE 1. You may assume that no memory allocation request will ever require more than MSIZE units of memory, and that MSIZE will never be larger than The remainder of the input will contain a sequence of allocation and deallocation requests, each on a line by itself. Each allocation request will include a unique positive integer ID that may also be later specified in a memory deallocation request. Examples of allocation and deallocation requests are provided below, and sample input is provided on Loki. Your program is to demonstrate your understanding of the first fit memory management algorithm (and your programming prowess) by displaying the address associated with each requested memory allocation at the time it succeeds. All allocations and deallocations in this assignment are simulated. That is, the memory regions being allocated and deallocated are not real memory regions. Your program is only to keep track of the addresses associated with the simulated allocations. Again, the examples provided below will make this obvious. The First-Fit Algorithm The principal data structure used in the first-fit system is a linked list of unused memory regions; this list is traditionally called the free list. Each entry on this list will identify the address of the unused region and the size 1 of the unused region, and will also identify the next entry on the free list. In this program the entries on the free list are to be ordered by address. That is, each entry on the free list will have a larger address than its predecessor 2. As noted earlier, other than initialization, there are two basic operations to be performed: allocation and deallocation. The details of how these operations are to be implemented will now be described. Allocation of a request for N units of memory is performed by searching the free list for the first entry that has a size R N. If no such entry is found, then the allocation request is deferred (this is discussed later). If R = N, then the entry is removed from the free list and, in a real system, would be used to satisfy 1 We use the generic term unit for the smallest memory item that can be allocated. For many systems this may be a byte, but other systems have other smallest memory allocation sizes. 2 Recall that there are variations of first-fit in which the entries on the list are ordered in other ways. In particular, remember the discussions of best-fit, worst-fit, and next-fit from the text and the lectures.

2 the allocation request 3. Otherwise we have R > N. In this case, the first N units of memory 4 in the region are used to satisfy the allocation request (in the real system). The second part of the region 5, of size R N, remains on the free list. Deallocation of a previously allocated region of size N at address A has more steps than allocation. The first step is to find the correct location on the free list for the region of memory being deallocated. Recall that the free list is ordered by address, so the correct location will be after an entry with a smaller address (or the beginning of the list) and before an entry with a larger address (or the end of the list). Once the correct location on the free list is found, the memory being deallocated (N units at address A) is either added to the region identified by the previous free list entry P if A is the address immediately after the the region identified by P, or added to the free list as a new entry. Regardless of which of these two actions is taken, the free list entry now associated with the deallocated memory must then be coalesced with the following block if it exists and the memory regions are adjacent. Deferred Requests are those allocation requests that could not be completed immediately. When this happes, information about the request (the request ID and the number of memory units requested) is added to the end of a list of such deferred requests. Of course, this list is initially empty at the beginning of the program. Each time a deallocation is performed, then each entry on the deferred list should be examined to see if the memory it originally requested can now be allocated. If it can, then the entry should be removed from the deferred request list and the allocation action performed, as usual. The deferred request list is maintained in FIFO order. That is, the first deferred request essentially has priority over later deferred requests. An Example An illustration with real numbers will aid your understanding of these actions. Specifically, let s assume we have a region with 1024 bytes to use in satisfying allocation requests. Then assume we have the following allocation and deallocation requests to process, in the order given. ID Action 1 Allocate 200 bytes 2 Allocate 399 bytes 3 Allocate 500 bytes 4 Allocate 100 bytes 5 Allocate 300 bytes 6 Allocate 75 bytes 4 Deallocate 5 Deallocate 3 To facilitate later deallocation of a region, your program must maintain some data structure that records successful allocations, including the allocation ID, the size, and the address of each allocated region. 4 If the free list entry indicates the R units of memory start at address A, then these N units of memory will have addresses from A to A + N 1. 5 If the entire region of size R started at address A, then this remaining part of the region will start at address A + N.

3 Initially the free list has a single entry for a region of size 1024 at address 0. The first request (ID 1, allocate 200 units) is easy, since the first (and only) entry on the free list is larger than 200. That region is split into two parts. The region from 0 to 199 is used to satisfy the allocation request, and the region starting at address 200 with size 824 remains on the free list. The second request (ID 2, allocate 399 units) is also easily satisfied. A region of size 399 from address 200 to address 598 is used to satisfy the request, and the region starting at address 599 of size 425 remains on the free list. The third request (ID 3, allocate 500 units) cannot be immediately satisfied because there are no entries on the free list with a sufficient size. The request is therefore deferred. It is added to the end of a list of deferred requests, and will be considered again after each deallocation. The fourth request (ID 4, allocate 100 units) can be easily satisfied by splitting the free region at address 599 into two parts: 100 units at address 599 (as per the request) and the single free list region at address 699 of size 325. The fifth request (ID 5, allocate 300 units) is satisfied using memory starting at address 699, leaving a region of size 25 units on the free list starting at address 999. The sixth request (ID 6, allocate 75 units) cannot be satisfied immediately, so it is deferred. Remember that this deferred request is to be recorded in such a way that the first deferred request (ID 3) will be considered before this one when additional memory becomes available (that is, after each deallocation). The seventh request (ID 4, deallocate) asks for the 100 unit block at address 599 to be freed. Once this has been done, deferred requests must be considered. The first deferred request (ID 3) cannot be satisfied. But sufficient memory is available to complete the next deferred allocation request (ID 6); it s given 75 units at address 599, with the 25 unused units at address 674 being placed in a new node on the free list. The eighth and final request (ID 5, deallocate) frees the 300 byte block at address 699. Note that this region is adjacent to the region with 25 unused units starting at address 674, so those two regions are joined to yield a single region of size 350 units at address 674. There is only one deferred request pending (ID 3 for size 500 units), but there is still insufficient memory to satisfy that request. Details and Limits After reading MSIZE (1 MSIZE 2 20 ) and initializing the free list and any other data structures needed, your program should read and process requests for allocation or deallocation, one at a time, until the end of input (end of file on the standard input) is encountered. Each request will be on a single line that begins with a unique positive integer ID (1 ID) used to identify the request in the input and in the output. No two allocation requests will ever have the same ID, but each deallocation request must contain the ID of a previously successful allocation. The input data used to test your solution will never attempt to deallocate an allocation that is currently deferred, but your solution should detect this case if it should exist, since that would indicate either an error in the input data or your solution! Although the IDs used in the earlier example s allocation requests were sequential, this need not be the case in actual test data. After theid in a request there will appear some whitespace blanks and/or tab characters and either '+' or ' ' to indicate an allocation request or a deallocation request, respectively. In the allocation case,

4 there will also be additional whitespace and a positive integer ASIZE (1 ASIZE MSIZE) that specifies the size of the region to be allocated. After reading each request, your program should display a line that indicates the request that is being processed; these should look like this: Request ID 52: allocate 73 units. Request ID 35: deallocate. Each line for an allocation request should be followed by or Success; addr = as appropriate. Note that the address in the Success message should be the address at which the region allocated for the request begins. After each deallocation request you should display a line that says Additionally, for each deferred request that can be successfully accommodated as a result of a deallocation, display a line that says Deferred request 59 allocated; addr = 500. If multiple deferred requests can be performed as the result of a deallocation, then the messages announcing their successful allocations should be given in the order the requests were deferred. Of course, the IDs and address values in each of these are just examples. Keep in mind that the addresses used in the program for free blocks and allocations are not real memory addresses they are simulated memory addresses. Your program should not be doing dynamic memory allocation for blocks of the sizes used in the progam. Naturally you may use dynamically-allocated data structures to represent the nodes in the free list and other data structures as needed by your solution. Sample Input and Output The instructor s solution to this assignment and files containing sample input are available on Loki in the directory/home/stanw/csci4500. The instructor s solution is in the file named prog3. Like your solution should do, it reads input data from the standard input. The instructor s solution also recognizes the v option on the command line. This causes that solution to produce considerable additional (verbose) output. For example, after each input request has been completed, the program will display the status of each request that has been encountered (active that is, still allocated, deferred, or freed), and the identification of the regions on the free list. Your solution need not include this feature. The sample shown below is the input used the earlier discussion, and is found in the file prog3.in0 on Loki. Here s what it looks like:

5 The expected output for this input is as follows: Request ID 1: allocate 200 units. Success; addr = 0. Request ID 2: allocate 399 units. Success; addr = 200. Request ID 3: allocate 500 units. Request ID 4: allocate 100 units. Success; addr = 599. Request ID 5: allocate 300 units. Success; addr = 699. Request ID 6: allocate 75 units. Request ID 4: deallocate. Deferred request 6 allocated; addr = 599 Request ID 5: deallocate. There are several additional test cases provided, appropriately named. The expected output for each test case can be obtained using the instructor s solution. You should also prepare and use your own data for testing (although it should not be placed in the submission directory). Requirements You must write (and test) a C, C++, Java or Python program that performs the tasks associated with the first fit memory management system as described above. You should ideally have a single file of source code, appropriately named (that is, useprog3 as part of the name). That file (or multiple files, if necessary) should be located in a top-level directory named csci prog3 sometime before Thursday, April 28, 2016 at 11:59 PM. At that time, the contents of that directory will be copied to the instructor s directory for grading. A template (partial solution) for a C solution to this assignment can be found in thecsci4500 directory. It is named prog3_temp.c. You are free to use this source code as the basis for your solution if you wish. You are not, however, required to use this partial solution. Locations in the code that are marked XXX WORK NEEDED obviously will require additional work. There may also be other modifications required to the code. You may work with one or two other students on this assignment that is, groups as large as three students are acceptable. If you work in a group with others, you must clearly indicate the names of all individuals in the group in a comment near the top of the source code (you should indicate the author of your code in all cases, even if you are working by yourself). You should also submit only one solution from the group for evaluation. Each individual in the group will receive the same evaluation. As always, please contact the instructor if you have questions, and periodically check the class web site for any additions or corrections to this assignment.