html>

Synchronization with Semaphores

The too-much-milk solution is much too complicated. The problem is that the mutual exclusion mechanism was too simple-minded: it used only atomic reads and writes. This is sufficient, but unpleasant. It would be unbearable to extend that mechanism to many processes. Let's look at more powerful, higher-level mechanisms.

Requirements for a mutual exclusion mechanism:

Must allow only one process into a critical section at a time.
If several requests at once, must allow one process to proceed.
Processes must be able to go on vacation outside critical section.

Desirable properties for a mutual exclusion mechanism:

Fairness: if several processes waiting, let each in eventually.
Efficiency: don't use up substantial amounts of resources when waiting. E.g. no busy waiting.
Simplicity: should be easy to use (e.g. just bracket the critical sections).

Desirable properties of processes using the mechanism:

Always lock before manipulating shared data.
Always unlock after manipulating shared data.
Do not lock again if already locked.
Do not unlock if not locked by you (usually: there are a few exceptions to this).
Do not spend large amounts of time in critical section.

The Binary Semaphore

A synchronization variable that takes only the values 0 and 1. Invented by Edsger Dijkstra in the mid 60's. It has two atomic operations:

P(s): If s==1 then set s=0 and proceed; else wait.

V(s): If there is a thread waiting on s, then wake one such thread; else set s = 1.

Semaphores are simple and elegant and allow the solution of many interesting problems. They do a lot more than just mutual exclusion. Too much milk problem with semaphores:

Processes A & B
1       P(mutex);
2	     if (NoMilk) {
3		  BuyMilk;
4	}
5       V(mutex);

Note: mutex must initially be set to 1. What happens if it isn't?

Semaphores aren't provided by hardware. But they have several attractive properties:

Machine independent.
Simple.
Work with many processes.
Can have many different critical sections with different semaphores.
Can acquire many resources simultaneously (multiple Ps).
Can permit multiple processes into the critical section at once, if that is desirable.

Semaphores are used in two different ways:

Mutual exclusion: to ensure that only one process is accessing shared information at a time. If there are separate groups of data that can be accessed independently, there may be separate semaphores, one for each group of data. These semaphores are always binary semaphores. The Too-much-milk solution is an example of mutual exclusion using a binary semaphore.
Scheduling: to permit processes to wait for certain things to happen. If there are different groups of processes waiting for different things to happen, there will usually be a different semaphore for each group of processes. These semaphores aren't necessarily binary semaphores, but may be a more general type of semaphore called counting semaphores.

The Counting Semaphore

A synchronization variable that takes on nonnegative integer values. Again, there are only two atomic operations allowed on the variable.

P(s): If s>0 then set s = s-1 and proceed; else wait.

V(s): If there is a thread waiting on s, then wake one such thread; else set s = s+1.

Counting Semaphore Example: Producer & Consumer.

Suppose one thread is creating information that is going to be used by another thread, e.g. suppose one thread is reading information from the disk, and another thread will compile that information from soure code to binary. The treads shouldn't have to operate in perfect lock-step: The producer should be able to get ahead of the consumer.

Producer: creates copies of a resource.

Consumer: uses up (destroys) copies of a resource.

Buffers: used to hold information after consumer has created it but before consumer has used it.

Synchronization: keeping producer and consumer in step.

Define constraints (definition of what is ``correct'').

Consumer must wait for producer to fill buffers. (scheduling)

Producer must wait for consumer to empty buffers, if all buffer space is in use. (scheduling)

Only one process must manipulate buffer pool at once. (mutual exclusion)

A separate semaphore is used for each constraint.

Initialization:

Put all buffers in pool of empties.

Initialize semaphores: emptiesAvl = numBuffers, fullsAvl= 0, mutex = 1;

Producer:

      P(emptiesAvl);
      P(mutex);
      get empty buffer from pool of empties;
      V(mutex);
      produce data in buffer;
      P(mutex);
      add full buffer to pool of fulls;
      V(mutex);
      V(fullsAvl);

Consumer:

      P(fullsAvl);
      P(mutex);
      get full buffer from pool of fulls;
      V(mutex);
      consume data in buffer;
      P(mutex);
      add empty buffer to pool of empties;
      V(mutex);
      V(emptiesAvl);

Important questions:

Why does producer P(emptiesAvl) but V(fullsAvl)?
Why is order of Ps important?
Is order of Vs important?
Could we have separate semaphores for each pool?
How would this be extended to have 2 consumers?
Producers and consumers produces something much like Unix pipes.
THIS IS AN IMPORTANT EXAMPLE!

Another Semaphore Example: Readers & Writers
There is a shared database with readers and writers. It is safe for any number of readers to access the database simultaneously, but each writer must have exclusive access. Must use semaphores to enforce these policies. Example: checking account (statement-generators are readers, tellers are writers).
Writers are actually readers too.
Constraints:
Writers can only proceed if there are no active readers or writers.
Readers can only proceed if there are no active writers.
To keep track of the number of active readers, we will need a state variable R. How, we must make sure that only one thread can access the state variable at one time.
Initialize variables: binary semaphore mutex = 1; binary semaphore OK = 1; integer R = 0.
```
Readers:

       P(mutex);
       R = R+1;
       if (R==1) P(OK);
       V(mutex);
       Read;
       P(mutex);
       R = R-1;
       if (R==0) V(OK);
       V(mutex);

Writers:

       P(OK);
       Write;
       V(OK);
```
Notice that Readers can lock out any Writers, starving them. Notice also that we needed only binary semaphores. The next example will cute this Writer-starvation problem.

The Writers-Preference Readers & Writers Problem Constraints:
Writers can only proceed if there are no active readers or writers.
Readers can only proceed if there are no active or waiting writers.
To keep track of who's reading and writing, we will need need some shared state variables that must be protected.
State variables:
AR = number of active readers.
WR = number of waiting readers.
AW = number of active writers.
WW = number of waiting writers.
AW is always 0 or 1.
AR and AW may not both be non-zero.
Initialization:
OKToRead = 0; OKToWrite = 0; Mutex = 1;
AR = WR = AW = WW = 0;
Scheduling: writers get preference.
```
Readers:

P(Mutex);
if ((AW+WW) == 0) {
	V(OKToRead);
	AR = AR+1;
} else {
	WR = WR+1;
}
V(Mutex);
P(OKToRead);
Read;
P(Mutex);
AR = AR-1;
if (AR==0 && WW>0) {
	V(OKToWrite);
	AW = AW+1;
	WW = WW-1;
}
V(Mutex);

Writers:

P(Mutex);
if ((AW+AR+WW) == 0) {
	V(OKToWrite);
	AW = AW+1;
} else {
	WW = WW+1;
}
V(Mutex);
P(OKToWrite);
Write;
P(Mutex);
AW = AW-1;
if (WW>0) {
	V(OKToWrite);
	AW = AW+1;
	WW = WW-1;
} else while (WR>0) {
	V(OKToRead);
	AR = AR+1;
	WR = WR-1;
}
V(Mutex);
```
Go through a complicated example:
- Reader enters and leaves system.
- Writer enters and leaves system.
- Two readers enter system.
- Writer enters system and waits.
- Reader enters system and waits.
- Readers leave system, writer continues.
- Writer leaves system, last reader continues and leaves.
Questions:
- In case of conflict between readers and writers, who gets priority?
- Is the WW necessary in the writer's first if?
- Can OKToRead ever get greater than 1? What about OKToWrite?
- Is the first writer to execute P(Mutex) guaranteed to be the first writer to access the data?