Synchronization Problems
+ +Notes:
+ +- +Please use real binary semaphores, counting semaphores, +or monitors. If you invent your own synchronization method, there is a 99% chance +you will get it wrong. Plus it makes it very hard to grade - we look very +closely and are more likely to find problems. If you must do this, provide an +implementation of your construct, because otherwise we don't know if:
+ +o +It is possible to implement
+ +o +How it works
+ +- +If you use semaphores, you must specify initial values +for your semaphores (mandatory).
+ +- +If you have a shared state, you should say what mutex +protects the shared state (not mandatory)
+ +- +With semaphores, if you wake up on one semaphore and then +call signal() to wake up the next waiter you might wake yourself up - +semaphores have history, so your next wait might be the one that awakes, +because the other waiters might have been context switchted out before they +call wait().
+ +- +With semaphores, you shouldn't wait while holding a +mutex, unless the routine signaling you does not need the mutex to wake you up.
+ +- +With monitors, you don't need to grab a mutex (or, +shudder, a condition variable) to access shared state. The monitor, by +definition, ensures mutual exclusion.
+ +- +With monitors, wait() doesn't take any parameters - it +just waits until somebody then calls signal().
+ +-
+When writing synchronization code, you should try to
+minimize the number of context switches and the number of times a process is
+awoken when it doesn't need to be. Ideally, in a while() loop, a process should
+only be woken once.
+
+
+wait(mutex)
+if (customers_waiting == 0) {
+ signal(mutex);
+ wait(barber_sleeping);
+ wait(mutex);
+}
+customers_waiting--;
+signal(mutex);
+signal(customer_queue);
+do_cut_hair();
+signal(cut_done);
+
+
+Customer Code
+wait(mutex);
+if (customers_waiting == n) {
+ signal(mutex);
+ return;
+}
+customers_waiting++;
+if (customers_waiting == 1) {
+ signal(barber_sleeping);
+}
+signal(mutex);
+wait(customer_queue);
+get_hair_cut();
+wait(cut_done);
+
+
+As a monitor
+
+
+monitor barbershop {
+ int num_waiting;
+ condition get_cut;
+ condition barber_asleep;
+ condition in_chair;
+ condition cut_done;
+
+ Barber routine
+ barber() {
+ while (1);
+ while (num_waiting == 0) {
+ barber_asleep.wait();
+ }
+ customer_waiting.signal();
+ in_chair.wait();
+ give_hait_cut();
+ cut_done.signal();
+ }
+ Customer routine
+ customer () {
+ if (num_waiting == n) {
+ return;
+ }
+ if (num_waiting == 0) {
+ barber_asleep.signal();
+ }
+ customer_waiting.wait();
+ in_char.signal();
+ get_hair_cut();
+ cut_done.wait();
+ }
+
+
+
7. +7.9. The Cigarette-Smokers Problem.
+ +Semaphores +are a convenient mechanism for implementing this, because they remember what +elements are on the table.
+ +Sempahore TobaccoAndPaper = 0;
+Sempahore PaperAndMatches = 0;
+Semaphore MatchesAndTobacco = 0;
+Sempaphore DoneSmoking = 1;
void agent()
+{
+ wait(DoneSmoking);
+ int r = rand() % 3;
+ //
+ // Signal which ever combination was
+ // chosen.
+ //
+
+
+ switch( r ) {
+ case 0:
+signal(TobaccoAndPaper);
+ break;
+ case 1:
+signal(PaperAndMatches);
+ break;
+ case 2:
+signal(MatchesAndTobacco);
+ break;
+ }
+}
+
+void Smoker_A()
+{
+ while(true) {
+
+ //
+ // Wait for our
+two ingredients
+ //
+
+
+wait(TobaccoAndPaper);
+ smoke();
+
+ //
+ // Signal that
+we're done smoking
+ // so the next
+agent can put down
+ // ingredients.
+ //
+
+
+signal(DoneSmoking);
+ }
+}
+
+
Smoker
+b and c are similar.
+ +
+
+8. +7.15. File-synchronization
+ ++From the book you should know how to use a conditional-wait construct (priority-based signaling), so we'll use it here. We'll assume for simplicity that no +process has an id greater than or equal to n (or we'd just print an error +message).
+ +type file = monitor
var space_available: binary condition total: integer procedure entry file_open(id) begin while (total + id >= n) space_available.wait(id) total = total + id; if (total < n - 1) space_available.signal(); end procedure entry file_close(id) begin total = total - id; space_available.signal(); end
+
+What +happens here? As long as the incoming processes find adequate space available +(i.e. sums less than n), they will claim that space and open the file. Note +that since we're using a binary condition, we can signal() at will even if +nothing is waiting. If a process finds inadequate space, it will block. When a +process is done, it wakes up the process with the smallest id (the most likely +to fit in the available space). This process, upon waking, then signals the +next process if space is still available, but only after successfully claiming +its own space. At some point (quite possibly with the first process), the space +made available may not be enough for the waking process, and so a process will +be woken up prematurely. This is what the loop is for; it will immediately +block again.
+ + + +