Strictly speaking,a mutex is locking mechanismused to synchronize access to a resource. Only one task (can be a thread or process based on OS abstraction) can acquire the mutex. It means there will be ownership associated with mutex, and only the owner can release the lock (mutex).

Semaphore is signaling mechanism(“I am done, you can carry on” kind of signal). For example, if you are listening songs (assume it as one task) on your mobile and at the same time your friend called you, an interrupt will be triggered upon which an interrupt service routine (ISR) will signal the call processing task to wakeup.

A Semaphore is a thread synchronization construct that can be used either to send signals between threads to avoidmissed signals, or to guard acritical sectionlike you would with alock. Java 5 comes with semaphore implementations in thejava.util.concurrentpackage so you don't have to implement your own semaphores. Still, it can be useful to know the theory behind their implementation and use.

Java 5 comes with a built-inSemaphoreso you don't have to implement your own. You can read more about it in thejava.util.concurrent.Semaphoretext, in myjava.util.concurrenttutorial.

Simple Semaphore

Here is a simpleSemaphoreimplementation:

public class Semaphore {
  private boolean signal = false;

  public synchronized void take() {
    this.signal = true;
    this.notify();
  }

  public synchronized void release() throws InterruptedException{
    while(!this.signal) wait();
    this.signal = false;
  }

}

Thetake()method sends a signal which is stored internally in theSemaphore. Therelease()method waits for a signal. When received the signal flag is cleared again, and therelease()method exited.

Using a semaphore like this you can avoid missed signals. You will calltake()instead ofnotify()andrelease()instead ofwait(). If the call totake()happens before the call torelease()the thread callingrelease()will still know thattake()was called, because the signal is stored internally in thesignalvariable. This is not the case withwait()andnotify().

The namestake()andrelease()may seem a bit odd when using a semaphore for signaling. The names origin from the use of semaphores as locks, as explained later in this text. In that case the names make more sense.

Using Semaphores for Signaling

Here is a simplified example of two threads signaling each other using aSemaphore:

Semaphore semaphore = new Semaphore();

SendingThread sender = new SendingThread(semaphore);

ReceivingThread receiver = new ReceivingThread(semaphore);

receiver.start();
sender.start();

public class SendingThread {
  Semaphore semaphore = null;

  public SendingThread(Semaphore semaphore){
    this.semaphore = semaphore;
  }

  public void run(){
    while(true){
      //do something, then signal
      this.semaphore.take();

    }
  }
}

public class RecevingThread {
  Semaphore semaphore = null;

  public ReceivingThread(Semaphore semaphore){
    this.semaphore = semaphore;
  }

  public void run(){
    while(true){
      this.semaphore.release();
      //receive signal, then do something...
    }
  }
}

Counting Semaphore

TheSemaphoreimplementation in the previous section does not count the number of signals sent to it bytake()method calls. We can change theSemaphoreto do so. This is called a counting semaphore. Here is a simple implementation of a counting semaphore:

public class CountingSemaphore {
  private int signals = 0;

  public synchronized void take() {
    this.signals++;
    this.notify();
  }

  public synchronized void release() throws InterruptedException{
    while(this.signals == 0) wait();
    this.signals--;
  }

}

Bounded Semaphore

TheCoutingSemaphorehas no upper bound on how many signals it can store. We can change the semaphore implementation to have an upper bound, like this:

public class BoundedSemaphore {
  private int signals = 0;
  private int bound   = 0;

  public BoundedSemaphore(int upperBound){
    this.bound = upperBound;
  }

  public synchronized void take() throws InterruptedException{
    while(this.signals == bound) wait();
    this.signals++;
    this.notify();
  }

  public synchronized void release() throws InterruptedException{
    while(this.signals == 0) wait();
    this.signals--;
    this.notify();
  }
}

Notice how thetake()method now blocks if the number of signals is equal to the upper bound. Not until a thread has calledrelease()will the thread callingtake()be allowed to deliver its signal, if theBoundedSemaphorehas reached its upper signal limit.

Using Semaphores as Locks

It is possible to use a bounded semaphore as a lock. To do so, set the upper bound to 1, and have the call totake()andrelease()guard the critical section. Here is an example:

BoundedSemaphore semaphore = new BoundedSemaphore(1);

...

semaphore.take();

try{
  //critical section
} finally {
  semaphore.release();
}

In contrast to the signaling use case the methodstake()andrelease()are now called by the same thread. Since only one thread is allowed to take the semaphore, all other threads callingtake()will be blocked untilrelease()is called. The call torelease()will never block since there has always been a call totake()first.

You can also use a bounded semaphore to limit the number of threads allowed into a section of code. For instance, in the example above, what would happen if you set the limit of theBoundedSemaphoreto 5? 5 threads would be allowed to enter the critical section at a time. You would have to make sure though, that the thread operations do not conflict for these 5 threads, or you application will fail.

Therelase()method is called from inside a finally-block to make sure it is called even if an exception is thrown from the critical section.