# HW/Study Guide. Synchronization Make sure you understand the HW problems!

## Presentation on theme: "HW/Study Guide. Synchronization Make sure you understand the HW problems!"— Presentation transcript:

HW/Study Guide

Synchronization Make sure you understand the HW problems!

global shared int counter = 0, BUFFER_SIZE = 10 ; Producer: while (1) { while (counter == BUFFER_SIZE); // do nothing buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; counter++; }

Consumer: while (1) { while (counter == 0); // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; // consume the item }

Identify the race condition in this version of the consumer/producer problem. –The race condition is the incrementing and decrementing of the shared variable counter.

Fix this race condition using the TestAndSet hardware instruction. global shared int counter = 0, BUFFER_SIZE = 10 ; shared int lock = 0 ; Producer: while (1) { while (counter == BUFFER_SIZE); // do nothing buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; while (TestAndSet(lock) == 1) ; counter++; lock = 0 ; }

Consumer: while (1) { while (counter == 0); // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; while (TestAndSet(lock) == 1) ; //busy wait counter--; lock = 0 ; } global shared int counter = 0, BUFFER_SIZE = 10 ; shared int lock = 0 ;

Now assume there is still one producer but there are now two consumers. –Does this introduce any additional race conditions (the correct answer is yes!)

If so, where does it occur? –The race condition occurs when the variable out is accessed since this is now shared by the two consumers. Now fix this additional race condition using a semaphore.

Consumer: while (1) { while (counter == 0); // do nothing wait(mutex) ; nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; signal(mutex) ; while (TestAndSet(lock) == 1) ; //busy wait counter--; lock = 0 ; } Note that the producer code does NOT have to be modified since it does not use out. global shared int counter = 0, BUFFER_SIZE = 10 ; shared int lock = 0 ; global shared int out = 0 ; //Now the two consumers must share out. struct semaphore mutex = 1 ; //Must supply the semaphore

Assume I have just learned about using semaphores to synchronize the order in which certain statements are executed. I think this is really cool, and want to give it a try. So I want to use semaphores to enforce the following execution order: –Statement S1 of process P1 executes before statement S2 of process P2. –Statement S2 of process P2 executes before statement S3 of Process P3.

Statement S3 of process P3 executes before Statement S1 of process P1. Use semaphores to enforce this ordering, or, show how this may not be such a great idea (i.e., what is the problem here?).

This ordering cannot be enforced since it creates a cyclic waiting condition that would result in deadlock. This can be seen clearly when you look at the requested ordering of the statements: S1  S2  S3 

Now assume we have four processes and want Statement S1 in P1 to execute before statement S2 in P2 before S3 in P3. Also, we want Statement S4 in P4 to execute after S2 in P2. Use semaphores to enforce this ordering. You must explicitly initialize any semaphores you use. struct semaphore S1 = 0 ; struct semaphore S2 = 0 ; P1:P2:P3:P4: S1 ; wait(S1) ; wait(S2) ; wait(S2) ; signal(S1) ; S2 ; S3 ; S4 ; signal(S2) ;

Assume there is one producer process and one consumer process, and that they share a buffer with 10 slots. Implement the producer/consumer problem using semaphores. You must explicitly initialize the semaphores that you use.

BUFFER_SIZE = 10 ; struct semaphore full = 0 ; struct semaphore empty = 10 ; Producer: while (1) { wait(empty) ; buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; signal(full) ; }

Consumer: while (1) { wait(full) ; nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; signal(empty) ; }

Paging Assume a 16-bit virtual address space with pages that are 2048 bytes. How many pages are in the logical address space? –The number of bits required to access any byte in the page (i.e., the offset) is 11. This leaves 5 bits for the logical page. Thus there are 2^5 or 32 pages.

Paging Consider the page table (shown on the next slide) for some process in this same system, and assume the logical address is 2052. To what physical address will this logical address be mapped? Show the steps you took to determine this address.

Step 1: Convert to binary: 2052 = 00010 00000000100. Step 2: Take the top most 5 bits and use them as an index into the process page table. 00010 00000000100. 0 2 1 3 21

Step 3: Take the physical page frame number from the page table 00010 0 2 1 3 21 00001

Step 4: Concatenate the offset to the physical page frame to get final address. 00010 0 2 1 3 21 0000100000000100 = 2052.

What is the Translation Lookaside buffer? –A very fast associative memory that caches page table entries. What purpose does it serve? –It avoids having to go to the page table in memory if the entry is found in the Translation Lookaside buffer. Thus it avoids the latency of accessing main memory.

Consider a 64-bit address space with 4K pages. How many pages are there in this virtual address space? –Since the page offset requires 12 bits this leaves 54 bits for the logical page number. Thus there are 2^54 logical pages in the address space. Is this a big number? –Yes, it is a big number. You will most likely be asked to work through a two-level page table example.

Similar presentations