Homework Assignment #4. Some of the questions are taken from the textbook, Operating Systems, Principles and Practice, by T. Anderson and M. Dahlin.

Transcription

1 CISC 3595/5595 Operating System Fall, 2015 Homework Assignment #4 Some of the questions are taken from the textbook, Operating Systems, Principles and Practice, by T. Anderson and M. Dahlin. 1 For the threadhello program in Figure 4.6, the procedure main() has local variables such as i and exitvalue. Are these variables per-trhead or shared state? Where does the compiler store these variables? Answer the above question for the parameter n of the function go(). 2 For the threadhello program, what is the minimum and maximum number of times that the main thread enters the WAITING state? 3 True or False: If a multi-threaded program runs correctly in all cases on a single processor computer, then it will run correctly if each thread is run on a separate processor of a shared-memory multiprocessor. Justify your ansswer.

2 4 The Too Much Milk to Peterson s Algorithm can be generalized to the Peterson s algorithm for mutual exclusion as below 1. int notes[2]; //note[0] for thread 0, note[1] for thread 1 2. int turn; // code for thread i, i=0, 1 // before critical section (i.e., access shared variables) 3. notes[i] = 1; //note that current thread i is interested 4. turn = i; //set flag 5. while (notes[1-i] == 1 && turn== i); //spin lock, busy waiting 6. HERE IS CRITICAL SECTION //after critical section 7. notes [i] = 0; // departure leaving critical section (a) if thread 0, and 1 tries to enter crucial section simultaneously, what happens? Considering several possible interleaving of two threads. (b) Does this algorithm work if the compiler or hardware might reorder instructions? Give an example. (c) How could you use memory barrier to avoid problems noted above? 2

3 5 For the TSQueue sample code included below, answer the following questions: (a) Precisely describe the set of possible outputs that could occur when the program is run: (b) If we declare the following in main function, and pass the pointers to queues[i] to each thread, will the thread be able to access the TSQueue? TSQueue queues[3]; (c) Why we shouldnt do the above, i.e., declare shared objects/variables as dynamical variables? // Thread-safe queue interface const int MAX = 5; class TSQueue { // Synchronization variables Lock lock; // State variables int items[max]; int front; int nextempty; public: TSQueue(); ~TSQueue(){; bool tryinsert(int item); bool tryremove(int *item); ; // Initialize the queue to empty // and the lock to free. TSQueue::TSQueue() { front = nextempty = 0; // Try to insert an item. If the queue is // full, return false; otherwise return true. bool 3

4 TSQueue::tryInsert(int item) { bool success = false; if ((nextempty - front) < MAX) { items[nextempty % MAX] = item; nextempty++; success = true; return success; // Try to remove an item. If the queue is // empty, return false; otherwise return true. bool TSQueue::tryRemove(int *item) { bool success = false; if (front < nextempty) { *item = items[front % MAX]; front++; success = true; return success; // TSQueueMain.cc // Test code for TSQueue. int main(int argc, char **argv) { TSQueue *queues[3]; sthread_t workers[3]; int i, j; // Start worker threads to insert. for (i = 0; i < 3; i++) { queues[i] = new TSQueue(); thread_create_p(&workers[i], putsome, queues[i]); // Wait for some items to be put. thread_join(workers[0]); // Remove 20 items from each queue. for (i = 0; i < 3; i++) { printf("queue %d:\n", i); testremoval(&queues[i]); 4

5 // Insert 10 items into a queue. void *putsome(void *p) { TSQueue *queue = (TSQueue *)p; int i; for (i = 0; i < 10; i++) { queue->tryinsert(i); return NULL; // Remove 10 items from a queue. void testremoval(tsqueue *queue) { int i, item; for (i = 0; i < 10; j++) { if (queue->tryremove(&item)) printf("removed %d\n", item); else printf("nothing there.\n"); 6 To better understand Design Pattern on usage of conditional variables, annotate the following code at the given locations (marked as 1, 2, 3,...): SharedObject::someMethodThatWaits() { // Read and/or write shared state here. // Conditional Variables are stateless, used for // threads to wait on some condition. // 1. What condition is the cv used to wait for here? while (!testonsharedstate()) { // // cv.wait(&lock); //2. List what happens when calling wait on a cv // 3. What causes this thread to "return" from wait(). What // are the sequence of things happens before this thread // continutes to run from here: 5

6 assert(testonsharedstate()); // Read and/or write shared state here. SharedObject::someMethodThatSignals() { // Read and/or write shared state here. // If state has changed in a way that // could allow another thread to make // progress, i.e., render testonsharedstate() to be true // signal (or broadcast), // // cv.signal(); //4. What happens when calling signal on a cv? 7 Blocing Bounded Queue Answer the following questions about the BBQ examples listed below: // BBQ.h // Thread-safe blocking queue. const int MAX = 10; class BBQ{ // Synchronization variables Lock lock; CV itemadded; CV itemremoved; // State variables int items[max]; int front; int nextempty; public: BBQ(); ~BBQ() {; void insert(int item); int remove(); ; #endif // BBQ.cc 6

7 // thread-safe blocking queue // Wait until there is room and // then insert an item. void BBQ::insert(int item) { while ((nextempty - front) == MAX) { itemremoved.wait(&lock); items[nextempty % MAX] = item; nextempty++; itemadded.signal(); // Wait until there is an item and // then remove an item. int BBQ::remove() { int item; while (front == nextempty) { itemadded.wait(&lock); item = items[front % MAX]; front++; itemremoved.signal(); return item; // Initialize the queue to empty, // the lock to free, and the // condition variables to empty. BBQ::BBQ() { front = nextempty = 0; (a) Please read BBQ.h, BBQ.cpp and testbbq.cpp in labclass8, and make notes in the pseudocode above on what each of the function calls on lock and conditional variables maps to in Posix thread library functions. (You can use the following command to copy the sample codes while on erdos: cp -r ~xzhang/osfall15/labclass8. (b) Assuming Mesa semantics for the condtional variables, the implementation of the blocking bounded queue does not guarantee freedom from starvation: if a continuous stream of threads makes insert (or remove) calls, a waiting thread could wait forever. For example, a thread may call insert and wait in the while loop because the queue is full. Starvation would occur if every time another trhead removes an item from the queue and signals the waiting thread, a different thread calls 7

8 insert, sees that the queue is not full, and inserts an item before the waiting thread resumes. Come up a scenario (a sequence of events) that leads to starvation. (c) How can you test (using BBQ.cpp, BBQ.h and testbbq.cpp) whether the signal call on a conditional variables wake up threads in the waiting queue in a FIFO order? How would you do it? What do you find out? (d) Modify the code to ensure freedom from starvation so that if a thread waits in insert, it is guaranteed to proceed after a bounded number of remove() call complete, and vice versa. Note: Your implementation must work under Mesa semantics for conditional variables. 8 Exercise on Semaphore. The following is psedocode that demonstrate the usage of semaphore. // use semaphore to enforce cap on class size semaphore remain_seat=20; RegisterInClass(string studentname) { P(remain_seat); add studentname into class list DropClass (string studentname) { if (studentname is in class list) V(remain_seat); remove studentname from class list 8

9 IncreaseCap (int additionalseat) { // what to do here? i. What happens to the 21st student trying to register, suppose no one drops the class? ii. What is the value of remain seat after the 21st student try to register? How would you implement the IncreaseCap function? What s the value of remain seat after function call IncreaseCap (5)? 9 You have two options for this question: (easier) Implement the barrier (based upon the pseudocode provided in the textbook, in Figure 5.13 on page 235), and write a application (i.e., main) that creates multiple threads to test the object. Design and implement PriorityLock: Before entering a priority critical section, a thread calls PriorityLock::enter(priority). When the thread exits the critical section, it calls PriorityLock::exit(). If several threads are waiting to enter a priority critical section, the one with the numerically highest priority should be the next one allowed in. Implement PriorityLock using locks and conditional variables. Hint: You can refer to the FIFO blocking bounded queue in Section for inspiration and ideas. i. Define the state, and synchronization variables and describe the purpose of each. ii. implement the two member functions. 9

10 10