Movatterモバイル変換


[0]ホーム

URL:


Tech & Media Labs
Home
RSS
Java Concurrency
  1. Java Concurrency and Multithreading Tutorial
  2. Multithreading Benefits
  3. Multithreading Costs
  4. Concurrency Models
  5. Same-threading
  6. Single-threaded Concurrency
  7. Concurrency vs. Parallelism
  8. Creating and Starting Java Threads
  9. Java Virtual Threads
  10. Race Conditions and Critical Sections
  11. Thread Safety and Shared Resources
  12. Thread Safety and Immutability
  13. Java Memory Model
  14. Java Happens Before Guarantee
  15. Java Synchronized Blocks
  16. Java Volatile Keyword
  17. CPU Cache Coherence in Java Concurrency
  18. False Sharing in Java
  19. Java ThreadLocal
  20. Thread Signaling in Java
  21. Deadlock
  22. Deadlock Prevention
  23. Starvation and Fairness
  24. Nested Monitor Lockout
  25. Slipped Conditions
  26. Locks in Java
  27. Read / Write Locks in Java
  28. Reentrance Lockout
  29. Semaphores
  30. Blocking Queues
  31. The Producer Consumer Pattern
  32. Thread Pools
  33. Thread Congestion in Java
  34. Compare and Swap
  35. Anatomy of a Synchronizer
  36. Non-blocking Algorithms
  37. Amdahl's Law
  38. Java Concurrency References

Semaphores

Jakob Jenkov
Last update: 2014-08-08

A Semaphore is a thread synchronization construct that can be used either to send signals between threads to avoidmissed signals, or to guard acritical section like you would with alock. Java 5 comes with semaphore implementations in thejava.util.concurrent package 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-inSemaphore so you don't have to implement your own. You can read more about it in thejava.util.concurrent.Semaphore text, in myjava.util.concurrent tutorial.

Simple Semaphore

Here is a simpleSemaphore implementation:

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 thesignal variable. 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

TheSemaphore implementation in the previous section does not count the number of signals sent to it bytake() method calls. We can change theSemaphore to 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

TheCoutingSemaphore has 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 theBoundedSemaphore has 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 theBoundedSemaphore to 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.

Next:Blocking Queues

Jakob Jenkov

Featured Videos

Java ConcurrentMap + ConcurrentHashMap

Java Generics

Java ForkJoinPool

P2P Networks Introduction

















Copyright Jenkov Aps
Close TOC
All Tutorial Trails
All Trails
Table of contents (TOC) for this tutorial trail
Trail TOC
Table of contents (TOC) for this tutorial
Page TOC
Previous tutorial in this tutorial trail
Previous
Next tutorial in this tutorial trail
Next

[8]ページ先頭

©2009-2025 Movatter.jp