• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/9

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

9 Cards in this Set

  • Front
  • Back

What is the Boss-Worker forumula to calculate average execution time for requests?

time_to_finish_1_order * ceiling (num_orders / num_concurrent_threads)

What is the Pipeline forumula to calculate average execution time for requests?

time_to_finish_first_order + (remaining_orders * time_to_finish_last_stage)

How is a new process created?

1. Via fork


2. Via fork followed by exec


3. Via fork or fork followed by exec

Is there a benefit of multithreading on 1 CPU?

Yes. You can use multiple threads to hide latency from code that blocks processing.

In the (pseudo) code segments for the producer code and consumer code, mark and explain all the lines where there are errors.



Global Section


int in, out, buffer[BUFFERSIZE];


mutex_t m;


cond_var_t not_empty, not_full;




Producer Code


1. while (more_to_produce) {


2. mutex_lock(&m);


3. if (out == (in + 1) % BUFFERSIZE)) // buffer full


4. condition_wait(¬_full);


5. add_item(buffer[in]); // add item


6. in = (in + 1) % BUFFERSIZE


7. cond_broadcast(¬_empty);


8.


9. } // end producer code




Consumer Code


1. while (more_to_consume) {


2. mutex_lock(&m);


3. if (out == in) // buffer empty


4. condition_wait(¬_empty);


5. remove_item(out);


6. out = (out + 1) % BUFFERSIZE;


7. condition_signal(¬_empty);


8.


9. } // end consumer code

Solution




Producer code


Line 3: uses “if” instead of “while”


Line 4: condition_wait doesn’t specify a mutex


Line 7: since only 1 item is added, no need to broadcast, should signal instead


Line 8: missing the mutex_unlock




Consumer code


Line 4: condition_wait doesn’t specify a mutex


Line 7: condition_signal signals the wrong variable, should be signaling not_full


Line 8: missing the mutex_unlock operation

If the kernel cannot see user-level signal masks, then how is a signal delivered to a user-level thread (where the signal can be handled)?

Recall that all signals are intercepted by a user-level threading library handler, and the user-level threading library installs a handler. This handler determines which user-level thread, if any, the signal be delivered to, and then it takes the appropriate steps to deliver the signal.

The implementation of Solaris threads described in the paper "Beyond Multiprocessing: Multithreading the Sun OS Kernel", describes four key data structures used by the OS to support threads.For each of these data structures, list at least two elements they must contain:




Process


LWP


Kernel-threads


CPU

Process:


1. List of kernel level threads


2. User level registers


3. Virtual Address Space


4. Signal handlers




LWP:


1. User-level registers


2. System call arguments


3. Resource Usage Info




Kernel-threads:


1. Kernel-level registers


2. Scheduling info




CPU:


1. Current thread


2. List of kernel-level threads

An image web server has three stages with average execution times as follows:

Stage 1: read and parse request (10ms)


Stage 2: read and process image (30ms)


Stage 3: send image (20ms)




You have been asked to build a multi-threaded implementation of this server using the pipeline model. Using a pipeline model, answer the following questions:




1. How many threads will you allocate to each pipeline stage?


2. What is the expected execution time for 100 requests (in sec)?


3. What is the average throughput of this system (in req/sec)?




Assume there are infinite processing resources (CPU's, memory, etc.).

1. Threads should be allocated as follows:

Stage 1 should have 1 thread. This 1 thread will parse a new request every 10ms


Stage 2 should have 3 threads. The requests parsed by Stage 1 get passed to the threads in Stage 2. Each thread picks up a request and needs 30ms to process the image. Hence, we need 3 threads in order to pick up a new request as soon as Stage 1 passes it.


Stage 3 should have 2 threads. This is because Stage 2 will process an image and pass a request every 10ms (once the pipeline is filled). In this way, each Stage 3 thread will pick up a request and send an image in 20ms. Once the pipeline is filled, Stage 3 will be able to pick up a request and send the image every 10ms.




2. The first request will take 60ms. The last stage will continue delivering the remaining 99 requests at 10ms intervals. So, the total is 60 + (99 * 10ms) = 1050ms = 1.05s




3. 100 req / 1.05 sec = 95.2 req/s

A shared calendar supports three types of operations for reservations:


1. read


2. cancel


3. enter




Requests for cancellations should have priority above reads, who in turn have priority over new updates.




In pseudocode, write the critical section enter/exit code for the **read** operation.

//Read operation


Lock(&m)