# Lock-Based vs Lock-Free Concurrent Algorithms

DevFeed: [Lock-Based vs Lock-Free Concurrent Algorithms](<https://devfeed.tech/articles/lock-based-vs-lock-free-concurrent-algorithms-13634.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2013/08/lock-based-vs-lock-free-concurrent.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2013-08-26T10:48:00Z

Content type: opinion

Language: en

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

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Java](<https://devfeed.tech/topics/java.md>), [Algorithm](<https://devfeed.tech/topics/algorithm.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [algorithms](<https://devfeed.tech/tags/algorithms.md>), [atomic](<https://devfeed.tech/tags/atomic.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [java](<https://devfeed.tech/tags/java.md>), [jdk](<https://devfeed.tech/tags/jdk.md>), [lock-free](<https://devfeed.tech/tags/lock-free.md>), [locks](<https://devfeed.tech/tags/locks.md>), [performance](<https://devfeed.tech/tags/performance.md>), [review](<https://devfeed.tech/tags/review.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

This article reviews Java lock implementations, focusing on StampedLock and its optimistic-read design for systems with concurrent readers accessing shared state. It compares lock-based and lock-free approaches using a garbage-free spaceship-position API and a test harness across different threading and contention scenarios. The author argues that lock-free algorithms can often be a better solution for multiple-reader cases, while noting that results may vary across CPUs and operating systems.

## Source excerpt

Last week I attended a review session of the new JSR166 StampedLock run by Heinz Kabutz at the excellent JCrete unconference. StampedLock is an attempt to address the contention issues that arise in a system when multiple readers concurrently access shared state. StampedLock is designed to perform better than ReentrantReadWriteLock by taking an optimistic read approach. While attending the session a couple of things occurred to me. Firstly, I thought it was about time I reviewed the current status of Java lock implementations. Secondly, that although StampedLock looks like a good addition to the JDK, it seems to miss the fact that lock-free algorithms are often a better solution to the multiple reader case. Test Case To compare implementations I needed an API test case that would not favour a particular approach. For example, the API should be garbage free and allow the methods to be atomic. A simple test case is to design a spaceship that can be moved around a 2-dimensional space with the coordinates of its position available to be read atomically. At least 2 fields need to be read, or written, per transaction to make the concurrency interesting. /** * Interface to a concurrent representation of a ship that can move around * a 2 dimensional space with updates and reads performed concurrently. */ public interface Spaceship { /** * Read the position of the spaceship into the array of coordinates provided. * * @param coordinates into which the x and y coordinates should be read. * @return the number of attempts made to read the current state. */ int readPosition(final int[] coordinates); /** * Move the position of the spaceship by a delta to the x and y coordinates. * * @param xDelta delta by which the spaceship should be moved in the x-axis. * @param yDelta delta by which the spaceship should be moved in the y-axis. * @return the number of attempts made to write the new coordinates. */ int move(final int xDelta, final int yDelta); } The above API would be cleaner by