# Locks & Condition Variables - Latency Impact

DevFeed: [Locks & Condition Variables - Latency Impact](<https://devfeed.tech/articles/locks-condition-variables-latency-impact-13621.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/11/locks-condition-variables-latency.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-11-05T13:52:00Z

Content type: tutorial

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [Java](<https://devfeed.tech/topics/java.md>), [Low Latency](<https://devfeed.tech/topics/low-latency.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [infiniband](<https://devfeed.tech/tags/infiniband.md>), [java](<https://devfeed.tech/tags/java.md>), [latency](<https://devfeed.tech/tags/latency.md>), [linux](<https://devfeed.tech/tags/linux.md>), [locks](<https://devfeed.tech/tags/locks.md>), [low-latency](<https://devfeed.tech/tags/low-latency.md>), [performance](<https://devfeed.tech/tags/performance.md>), [thread](<https://devfeed.tech/tags/thread.md>), [threads](<https://devfeed.tech/tags/threads.md>), [windows](<https://devfeed.tech/tags/windows.md>)

## AI overview

This article measures the latency impact of using locks and condition variables to pass control between two Java threads. It reports that kernel arbitration and thread scheduling add substantially more latency than signaling with memory barriers, and that allowing the operating system to schedule threads across different cores can hurt low-latency performance through cache pollution.

## Source excerpt

In a previous article on Inter-Thread Latency I showed how it is possible to signal a state change between 2 threads with less than 50ns of latency. To many developers, writing concurrent code using locks is a scary experience. Writing concurrent code using lock-free algorithms, i.e. algorithms that rely on the use of memory barriers and an intimate understanding of the underlying memory models, can be totally terrifying. To me lock-free / non-blocking algorithms are like playing with explosives or corrosive chemicals, if you do not understand what you are doing, or show the ultimate respect, then very bad things can, and most likely will, happen! In this article, I'd like to illustrate the impact of using locks and the resulting latency they can impose on your designs. I want to use a very similar algorithm to that used in my previous inter-thread latency article to illustrate the ping-pong effect of handing control back and forth between 2 threads. In this case, rather than using a couple of volatile variables, I will employ a pair of condition variables to signal a state change so control can be passed back and forth. The Code import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; import static java.lang.System.out; public final class LockedSignallingLatency { private static final int ITERATIONS = 10 * 1000 * 1000; private static final Lock lock = new ReentrantLock(); private static final Condition sendCondition = lock.newCondition(); private static final Condition echoCondition = lock.newCondition(); private static long sendValue = -1L; private static long echoValue = -1L; public static void main(final String[] args) throws Exception { final Thread sendThread = new Thread(new SendRunner()); final Thread echoThread = new Thread(new EchoRunner()); final long start = System.nanoTime(); echoThread.start(); sendThread.start(); sendThread.join(); echoThread.join(); final long duration = Sys