Fastest Way for Java to write mutexes?

Question

Mutexes are pretty common in many programming languages, like e.g. C/C++. I miss them in Java. However, there are multiple ways I could write my own class Mutex:

• Using a simple synchronized keyword on Mutex.
• Using a binary semaphore.
• Using atomic variables, like discussed here.
• ...?

What is the fastest (best runtime) way? I think synchronized is most common, but what about performance?

Answer 1

Mutexes are pretty common in many programming languages, like e.g. C/C++. I miss them in Java.

Not sure I follow you (especially because you give the answer in your question).

public class SomeClass {
    private final Object mutex = new Object();

    public void someMethodThatNeedsAMutex() {
        synchronized(mutex) {
            //here you hold the mutex
        }
    }
}

Alternatively, you can simply make the whole method synchronized, which is equivalent to using this as the mutex object:

public class SomeClass {

    public synchronized void someMethodThatNeedsAMutex() {
        //here you hold the mutex
    }
}

What is the fastest (best runtime) way?

Acquiring / releasing a monitor is not going to be a significant performance issue per se (you can read this blog post to see an analysis of the impact). But if you have many threads fighting for the lock, it will create contention and degrade performance.

In that case, the best strategy is to not use mutexes by using "lock-free" algorithms if you are mostly reading data (as pointed out by Marko in the comments, lock-free uses CAS operations, which may involve retrying writes many times if you have lots of writing threads, eventually leading to worse performance) or even better, by avoiding to share too much stuff across threads.

Answer 2

The opposite is the case: Java designers solved it so well that you don't even recognize it: you don't need a first-class Mutex object, just the synchronized modifier.

If you have a special case where you want to juggle your mutexes in a non-nesting fashion, there's always the ReentrantLock and java.util.concurrent offers a cornucopia of synchronization tools that go way beyond the crude mutex.