DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • A Comprehensive Guide To Testing and Debugging AWS Lambda Functions
  • An Overview of Cloud Cryptography
  • How AI Will Change Agile Project Management
  • Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications

Trending

  • A Comprehensive Guide To Testing and Debugging AWS Lambda Functions
  • An Overview of Cloud Cryptography
  • How AI Will Change Agile Project Management
  • Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Java Concurrency: Semaphores

Java Concurrency: Semaphores

Jakob Jenkov user avatar by
Jakob Jenkov
·
Jun. 19, 08 · News
Like (1)
Save
Tweet
Share
56.78K Views

Join the DZone community and get the full member experience.

Join For Free

This text is part of my blog on Java Concurrency which by now contains 18 texts.

A Semaphore is a thread synchronization construct that can be used either to send signals between threads to avoid missed signals, or to guard a critical section like you would with a lock. Java 5 comes with semaphore implementations in the java.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.

Here is a list of the topics covered in this text:

  1. Simple Semaphore
  2. Using Semaphores for Signaling
  3. Counting Semaphore
  4. Bounded Semaphore
  5. Using Semaphores as Locks

Simple Semaphore

Here is a simple Semaphore 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;
}

}

The take() method sends a signal which is stored internally in the Semaphore. The release() method waits for a signal. When received the signal flag is cleared again, and the release() method exited.

Using a semaphore like this you can avoid missed signals. You will call take() instead of notify() and release() instead of wait(). If the call to take() happens before the call to release() the thread calling release() will still know that take() was called, because the signal is stored internally in the signal variable. This is not the case with wait() and notify().

The names take() and release() 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 a Semaphore:

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

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

The CoutingSemaphore 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.signal++;
this.notify();
}

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

Notice how the take() method now blocks if the number of signals is equal to the upper bound. Not until a thread has called receive will the thread calling take() be allowed to deliver its signal, if the BoundedSemaphore 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 to take() and release() 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 methods take() and release() are now called by the same thread. Since only one thread is allowed to take the semaphore, all other threads calling take() will be blocked until release() is called. The call to release() will never block since there has always been a call to take() 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 the BoundedSemaphore 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.

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

Semaphore (programming) Java (programming language) Signal

Published at DZone with permission of Jakob Jenkov. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • A Comprehensive Guide To Testing and Debugging AWS Lambda Functions
  • An Overview of Cloud Cryptography
  • How AI Will Change Agile Project Management
  • Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: