Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 7 Memory Management. Today Exam I Thursday thru Tuesday 79 Questions (50 match, 29 guess) 1 Sheet Handwritten Notes Project 3 – Jurassic Park.

Similar presentations

Presentation on theme: "Chapter 7 Memory Management. Today Exam I Thursday thru Tuesday 79 Questions (50 match, 29 guess) 1 Sheet Handwritten Notes Project 3 – Jurassic Park."— Presentation transcript:

1 Chapter 7 Memory Management

2 Today Exam I Thursday thru Tuesday 79 Questions (50 match, 29 guess) 1 Sheet Handwritten Notes Project 3 – Jurassic Park Chapter 7 – Memory Management BYU CS 345Memory Management2

3 Step 1: Delta Clock Implement delta clock. Design data structure to hold delta times/events. Program an insert delta clock function insertDeltaClock(int time, Semaphore* sem); High priority, mutex protected Add 1/10 second function to decrement top event and semSignal semaphore when 0 pollinterrupts or High priority, mutex protected. BYU CS 345Memory Management3 dc[5] dc[4]10 / sem1 dc[3]5 / sem2 dc[2]0 / sem3 dc[1]2 / sem4 dc[0]4 Project 3 Assignment Thoroughly test the operation of your delta clock before proceeding. os345p3.c Print Delta Clock (dc): int P3_dc(int argc, char* argv[]); Test Delta Clock (tdc): int P3_tdc(int argc, char* argv[]); int dcMonitorTask(int argc, char* argv[]); int timeTask(int argc, char* argv[]);

4 BYU CS 345Memory Management4 // *********************************************************************** // test delta clock int P3_tdc(int argc, char* argv[]) { createTask( "DC Test“, dcMonitorTask, 10, argc, argv); timeTaskID = createTask( "Time", timeTask, 10, argc, argv); return 0; } // end P3_tdc // *********************************************************************** // monitor the delta clock task int dcMonitorTask(int argc, char* argv[]) { int i, flg; char buf[32]; int ttime[10] = { 90, 300, 50, 170, 340, 300, 50, 300, 40, 110 }; for (i=0; i<10; i++) { sprintf(buf, "event[%d]", i); event[i] = createSemaphore(buf, BINARY, 0); insertDeltaClock(ttime[i], event[i]); } printDeltaClock(); while (numDeltaClock > 0) { SEM_WAIT(dcChange) flg = 0; for (i=0; i<10; i++) { if (event[i]->state ==1) { printf("\n event[%d] signaled", i); event[i]->state = 0; flg = 1; } if (flg) printDeltaClock(); } printf("\nNo more events in Delta Clock"); // kill dcMonitorTask tcb[timeTaskID].state = S_EXIT; return 0; } // end dcMonitorTask extern Semaphore* tics1sec; // ************************************************************************* // display time every tics1sec int timeTask(int argc, char* argv[]) { char svtime[64]; // ascii current time while (1) { SEM_WAIT(tics1sec) printf("\nTime = %s", myTime(svtime)); } return 0; } // end timeTask

5 Step 2: Car Tasks Implement simple car task. Design car functionality and Jurassic Park interface. (Don’t worry about passengers or drivers yet.) BYU CS 345Memory Management5 Project 3 Assignment Semaphore* fillSeat[NUM_CARS]; Semaphore* seatFilled[NUM_CARS]; Semaphore* rideOver[NUM_CARS]; ActionCar Task Park Task For each car seat: (3 times, then car takes off) SEM_WAIT(fillSeat[carID]); Get passenger Save passenger rideDone[] semaphore Get driver (if last passenger) Save driver driverDone semaphore SEM_SIGNAL(seatFilled[carID]);    SEM_SIGNAL(fillSeat[carID]); SEM_WAIT(seatFilled[carID]); Wait until ride over SEM_WAIT(rideOver[carID]);  SEM_SIGNAL(rideOver[carID]); Release driver SEM_SIGNAL(driverDone); Release passengers SEM_SIGNAL(rideDone[i]);

6 Step 2: Car Tasks (example) BYU CS 345Memory Management6 Project 3 Assignment // For each car, do 3 times: { SEM_WAIT(fillSeat[carID]); SWAP; // wait for available seat SEM_SIGNAL(getPassenger); SWAP; // signal for visitor SEM_WAIT(seatTaken); SWAP; // wait for visitor to reply... save passenger "rideover" semaphore... SEM_SIGNAL(passengerSeated); SWAP: // signal visitor in seat // if last passenger, get driver { SEM_WAIT(needDriverMutex); SWAP; // wakeup attendant SEM_SIGNAL(wakeupDriver); SWAP;... save driver "rideover" semaphore... // got driver (mutex) SEM_SIGNAL(needDriverMutex); SWAP; } SEM_SIGNAL(seatFilled[carID]); SWAP; // signal next seat ready } SEM_WAIT(rideOver[myID]); SWAP; // wait for ride over... release passengers and driver...

7 Design visitor functionality and car task interface. (Don’t worry about tickets yet.) Each task visitor should create its own timing semaphore, which is used for timing functions (ie, arrival delay, standing in lines, time in gift shop or museum.) The delta clock should be used to SEM_SIGNAL these semaphores. Park visitors should randomly arrive at the park over a 10 second period. In addition, visitors should stand in lines for a random time before requesting a ticket or entrance to the museum or gift shop (3 seconds maximum). The “SWAP” directive should be inserted after every line of code in your Jurassic Park simulation. Park critical code must be protected by the parkMutex mutex. The park simulation creates a “lostVisitor” task which sums critical variables in the park to detect any lost visitors. BYU CS 345Memory Management7 Step 3: Visitor Tasks Project 3 Assignment

8 Use resource semaphores (counting) to control access to the park, the number of tickets available, and the number of people allowed in the gift shop and museum. Use mutex semaphores (binary) to protect any critical sections of code within your implementation, such as when updating the delta clock, acquiring a driver to buy a ticket or drive a tour car, accessing global data, or sampling the state of a semaphore. Use semaphores (binary) to synchronize and communicate events between tasks, such as to awaken a driver, signal data is valid, signal a mode change, etc. BYU CS 345Memory Management8 Step 3: Visitor Tasks Project 3 Assignment

9 CS 345Lab 3 – Jurassic Park Semaphores Use resource semaphores (counting) to control access to the park, the number of tickets available, and the number of people allowed in the gift shop and museum. // create MAX_TICKETS tickets using counting semaphore tickets = createSemaphore("tickets", COUNTING, MAX_TICKETS); SWAP; // buy a ticket (consume) SEM_WAIT(tickets); SWAP; // resell ticket (produce) SEM_SIGNAL(tickets); SWAP; 9 Start with MAX_TICKETS

10 CS 345Lab 3 – Jurassic Park Semaphores Use mutex semaphores (binary) to protect any critical sections of code, such as when updating the delta clock, acquiring a driver to buy a ticket or drive a tour car, accessing global data, or sampling the state of a semaphore. // need ticket, (1 at a time) SEM_WAIT(getTicketMutex); SWAP; { // Signal needTicket, Signal wakeUpDriver, Wait ticketReady, } // allow next visitor to purchase ticket SEM_SIGNAL(getTicketMutex); SWAP; 10 Only 1 visitor at a time requesting a ticket

11 CS 345Lab 3 – Jurassic Park Semaphores Use signal semaphores (binary) to synchronize and communicate events between tasks, such as to awaken a driver, signal data is valid, etc. // signal need ticket (produce raised hand up) SEM_SIGNAL(needTicket);SWAP; // wakeup driver (produce wakeup call, driver consumes) SEM_SIGNAL(wakeupDriver);SWAP; // wait ticket available (consume, driver produced ticket) SEM_WAIT(ticketReady);SWAP; // buy ticket (produce driver consumes notification) SEM_SIGNAL(buyTicket);SWAP; // put hand down (consume, done) SEM_WAIT(needTicket);SWAP; 11

12 CS 345Lab 3 – Jurassic Park Shared Memory Shared memory can be implemented using C global memory when protected with mutex semaphores. // protect shared memory access SEM_WAIT(parkMutex); ;SWAP // access inside park variables myPark.numOutsidePark--; ;SWAP myPark.numInPark++; ;SWAP // release protect shared memory access SEM_SIGNAL(parkMutex); ;SWAP 12

13 CS 345Lab 3 – Jurassic Park Passing Semaphores Shared memory can be implemented using C global memory when protected with mutex semaphores. // signal resource ready SEM_WAIT(resourceMutex); SWAP; SEM_WAIT(needPassenger); SWAP: gSemaphore = mySemaphore; SWAP; SEM_SIGNAL(resourceReady); SWAP; SEM_WAIT(resourceAcquired); SWAP; SEM_SIGNAL(resourceMutex); SWAP; 13 // signal resource ready SEM_SIGNAL(needPassenger); SWAP; SEM_WAIT(resourceReady); SWAP: gSemaphore = mySemaphore; SWAP; SEM_SIGNAL(resourceAcquired); SWAP;

14 CS 345Lab 3 – Jurassic Park Jurassic Park struct Driver Status park.drivers[ ] # of Passengers[ ].passengers # Exited Park numExitedPark # Waiting to Enter Park numOutsidePark # Tickets Available numTicketsAvailable # in Park numInPark # Rides Taken numRidesTaken Ticket Line numInTicketLine # in Gift Shop numInGiftShop # in Museum numInMuseum Tour Car Line numInCarLine Gift Shop Line numInGiftLine Museum Line numInMuseumLine 14 typedef struct { int numOutsidePark; // # outside of park int numInPark; // # in park (P=#) int numTicketsAvailable; // # left to sell (T=#) int numRidesTaken; // # of tour rides taken (S=#) int numExitedPark; // # who have exited the park int numInTicketLine; // # in ticket line int numInMuseumLine; // # in museum line int numInMuseum; // # in museum int numInCarLine; // # in tour car line int numInCars; // # in tour cars int numInGiftLine; // # in gift shop line int numInGiftShop; // # in gift shop int drivers[NUM_DRIVERS]; // driver state (-1=T, 0=z, 1=A, 2=B, etc.) CAR cars[NUM_CARS]; // cars in park } JPARK;

15 Develop the driver task. Design driver functionality and interface with visitor/car tasks. Implement design and integrate with os345, visitor, and car tasks. (Now is the time to worry about ticket sales and driver duties.) Add ticket sales and driver responsibilities. When a driver is awakened, use the semTryLock function to determine if a driver or a ticket seller is needed. BYU CS 345Memory Management15 Step 4: Driver Tasks Project 3 Assignment

16 Driver Task BYU CS 345Memory Management16 int driverTask(int argc, char* argv[]) { char buf[32]; Semaphore* driverDone; int myID = atoi(argv[1]) - 1; SWAP; // get unique drive id printf(buf, "Starting driverTask%d", myID); SWAP; sprintf(buf, "driverDone%d", myID + 1); SWAP; driverDone = createSemaphore(buf, BINARY, 0); SWAP; // create notification event while(1) // such is my life!! { mySEM_WAIT(wakeupDriver); SWAP; // goto sleep if (mySEM_TRYLOCK(needDriver)) // i’m awake - driver needed? { // yes driverDoneSemaphore = driverDone; SWAP; // pass notification semaphore mySEM_SIGNAL(driverReady); SWAP; // driver is awake mySEM_WAIT(carReady); SWAP; // wait for car ready to go mySEM_WAIT(driverDone); SWAP; // drive ride } else if (mySEM_TRYLOCK(needTicket)) // someone need ticket? { // yes mySEM_WAIT(tickets); SWAP; // wait for ticket (counting) mySEM_SIGNAL(takeTicket); SWAP; // print a ticket (binary) } else break; // don’t bother me! } return 0; } // end driverTask Project 3 Assignment Should this be mutexed?

17 BYU CS 345Memory Management17 CS 345 Stalling’s Chapter#Project 1: Computer System Overview 2: Operating System Overview 4P1: Shell 3: Process Description and Control 4: Threads 4P2: Tasking 5: Concurrency: ME and Synchronization 6: Concurrency: Deadlock and Starvation 6P3: Jurassic Park 7: Memory Management 8: Virtual memory 6P4: Virtual Memory 9: Uniprocessor Scheduling 10: Multiprocessor and Real-Time Scheduling 6P5: Scheduling 11: I/O Management and Disk Scheduling 12: File Management 8P6: FAT Student Presentations6

18 Chapter 7 Learning Objectives After studying this chapter, you should be able to: Discuss the principal requirements for memory management. Understand the reason for memory partitioning and explain the various techniques that are used. Understand and explain the concept of paging. Understand and explain the concept of segmentation. Assess the relative advantages of paging and segmentation. Summarize key security issues related to memory management. Describe the concepts of loading and linking. BYU CS 345Memory Management18

19 BYU CS 345Memory Management19 Memory Management Requirements Relocation Users generally don’t know where they will be placed in main memory May swap in at a different place (pointers???) Generally handled by hardware Protection Prevent processes from interfering with the O.S. or other processes Often integrated with relocation Sharing Allow processes to share data/programs Logical Organization Support modules, shared subroutines Physical Organization Main memory verses secondary memory Overlaying Requirements

20 BYU CS 345Memory Management20 Address Binding A process must be tied to a physical address at some point (bound) Binding can take place at 3 times Compile time Always loaded to same memory address Load time relocatable code stays in same spot once loaded Execution time may be moved during execution special hardware needed source object Compiler/Assembler load module Linker Loader Executable

21 BYU CS 345Memory Management21 Memory Management Techniques Fixed Partitioning Divide memory into partitions at boot time, partition sizes may be equal or unequal but don’t change Simple but has internal fragmentation Dynamic Partitioning Create partitions as programs loaded Avoids internal fragmentation, but must deal with external fragmentation Simple Paging Divide memory into equal-size pages, load program into available pages No external fragmentation, small amount of internal fragmentation

22 BYU CS 345Memory Management22 Simple Segmentation Divide program into segments No internal fragmentation, some external fragmentation Virtual-Memory Paging Paging, but not all pages need to be in memory at one time Allows large virtual memory space More multiprogramming, overhead Virtual Memory Segmentation Like simple segmentation, but not all segments need to be in memory at one time Easy to share modules More multiprogramming, overhead Memory Management Techniques

23 BYU CS 345Memory Management23 Fixed Partitioning Main memory divided into static partitions Simple to implement Inefficient use of memory Small programs use entire partition Maximum active processes fixed Internal Fragmentation 8 M Operating System

24 BYU CS 345Memory Management24 Fixed Partitioning Variable-sized partitions assign smaller programs to smaller partitions lessens the problem, but still a problem Placement Which partition do we use? Want to use smallest possible partition What if there are no large jobs waiting? Can have a queue for each partition size, or one queue for all partitions Used by IBM OS/MFT, obsolete Smaller partition by using overlays Operating System 8 M 12 M 8 M 6 M 4 M 2 M

25 BYU CS 345Memory Management25 Placement Algorithm w/Partitions Equal-size partitions because all partitions are of equal size, it does not matter which partition is used Unequal-size partitions can assign each process to the smallest partition within which it will fit queue for each partition processes are assigned in such a way as to minimize wasted memory within a partition

26 BYU CS 345Memory Management26 Process Queues New Processes Operating System Operating System New Processes  When its time to load a process into main memory the smallest available partition that will hold the process is selected

27 BYU CS 345Memory Management27 Dynamic Partitioning Partitions are of variable length and number Process is allocated exactly as much memory as required Eventually get holes in the memory. external fragmentation Must use compaction to shift processes so they are contiguous and all free memory is in one block

28 BYU CS 345Memory Management28 Allocation Strategies First Fit Allocate the first spot in memory that is big enough to satisfy the requirements. Best Fit Search through all the spots, allocate the spot in memory that most closely matches requirements. Next Fit Scan memory from the location of the last placement and choose the next available block that is large enough. Worst Fit The largest free block of memory is used for bringing in a process.

29 BYU CS 345Memory Management29 Which Allocation Strategy? The first-fit algorithm is not only the simplest but usually the best and the fastest as well. May litter the front end with small free partitions that must be searched over on subsequent first-fit passes. The next-fit algorithm will more frequently lead to an allocation from a free block at the end of memory. Results in fragmenting the largest block of free memory. Compaction may be required more frequently. Best-fit is usually the worst performer. Guarantees the fragment left behind is as small as possible. Main memory quickly littered by blocks too small to satisfy memory allocation requests.

30 BYU CS 345Memory Management30 Dynamic Partitioning Placement Algorithm Last allocated block (14K) Before 8K 12K 22K 18K 6K 8K 14K 36K Free block Allocated block After 8K 12K 6K 8K 14K 6K 2K 20K Allocate 18K First Fit Next Fit Best Fit

31 BYU CS 345Memory Management31 Memory Fragmentation As memory is allocated and deallocated fragmentation occurs External - Enough space exists to launch a program, but it is not contiguous Internal - Allocate more memory than asked for to avoid having very small holes Memory Fragmentation

32 BYU CS 345Memory Management32 Memory Fragmentation Statistical analysis shows that given N allocated blocks, another 0.5 N blocks will be lost due to fragmentation. On average, 1/3 of memory is unusable (50-percent rule) Solution – Compaction. Move allocated memory blocks so they are contiguous Run compaction algorithm periodically How often? When to schedule? Memory Fragmentation

33 BYU CS 345Memory Management33 Buddy System Tries to allow a variety of block sizes while avoiding excess fragmentation Blocks generally are of size 2 k, for a suitable range of k Initially, all memory is one block All sizes are rounded up to 2 s If a block of size 2 s is available, allocate it Else find a block of size 2 s+1 and split it in half to create two buddies If two buddies are both free, combine them into a larger block Largely replaced by paging Seen in parallel systems and Unix kernel memory allocation Buddy System

34 BYU CS 345Memory Management34 Addresses Logical reference to a memory location independent of the current assignment of data to memory translation must be made to the physical address Relative address expressed as a location relative to some known point Physical the absolute address or actual location Relocation

35 BYU CS 345Memory Management35 Hardware Support for Relocation Interrupt to operating system Process image in main memory Relative address Absolute address Adder Comparator Base Register Bounds Register Relocation Process Control Block Program Data / Stack Kernel Stack

36 BYU CS 345Memory Management36 Base/Bounds Relocation Base Register Holds beginning physical address Add to all program addresses Bounds Register Used to detect accesses beyond the end of the allocated memory May have length instead of end address Provides protection to system Easy to move programs in memory These values are set when the process is loaded and when the process is swapped in Largely replaced by paging Relocation

37 BYU CS 345Memory Management37 Paging Partition memory into small equal-size chunks and divide each process into the same size chunks The chunks of a process are called pages and chunks of memory are called frames Operating system maintains a page table for each process contains the frame location for each page in the process memory address consist of a page number and offset within the page Paging

38 BYU CS 345Memory Management38 Paging (continued…) Page size typically a power of 2 to simplify the paging hardware Example (16-bit address, 1K pages) 010101 011011010 Top 6 bits (010101)= page # Bottom 10 bits (011011010) = offset within page Common sizes: 512 bytes, 1K, 4K ABCDFree 0 1 2 3 - - - 7 8 9 10 4 5 6 11 12 13 14 Paging

39 BYU CS 345Memory Management39 B.0 B.1 B.2 A.0 A.1 A.2 A.3 Paging Frame Number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 C.0 C.1 C.2 C.3 D.0 D.1 D.2 D.3 D.4 0 1 2 3 Process A 0 1 2 3 0 1 2 Process B 4 5 6 0 1 2 3 Process C 7 8 9 10 0 1 2 3 4 4 5 6 11 12 Process D Free Frame List 13 14 Paging 0 1 2 Process B ---

40 BYU CS 345Memory Management40 Segmentation Program views memory as a set of segments of varying sizes Supports user view of memory Easy to handle growing data structures Easy to share libraries, memory Privileges can be applied to a segment Programs may use multiple segments Implemented with a segment table Array of base-limit register pairs Beginning address (segment base) Size (segment limit) Status bits (Present, Modified, Accessed, Permission, Protection) Segmentation

41 BYU CS 345Memory Management41 Segmentation/Paging In Pentium systems CPU generate logical addresses Segmentation unit produces a linear address Paging unit generates physical address in memory (Equivalent to an MMU) Segmentation CPU Segmentation Unit logical address Paging Unit linear address Physical Memory physical address

42 BYU CS 345Memory Management42

43 Exam I 27. Why would early versions of the UNIX operating system be unsuitable for real-time applications? a.Because a process executing in kernel mode acts like a user functions. b.Because a process executing in user mode may not be preempted. c.Because maximum latency to process an interrupt could not be guaranteed. d.Untrue. UNIX is well suited for real-time applications. 30. During its lifetime, a process moves among a number of states. The most important of these are a.Executing and Blocked. b.Idaho, Utah, Wyoming, and Nebraska. c.New, Running, and Suspended. d.Ready, Running, and Blocked. 62. What are the software contexts in which concurrency becomes an issue? e. Multiprogramming, modularity, system software BYU CS 345Memory Management43

Download ppt "Chapter 7 Memory Management. Today Exam I Thursday thru Tuesday 79 Questions (50 match, 29 guess) 1 Sheet Handwritten Notes Project 3 – Jurassic Park."

Similar presentations

Ads by Google