Is there a viable use case where Java synchronized keyword is better than Atomics?

Question

I've not much experience with threading, but I wrote a nifty non-blocking sequential Id generator with Atomics.... It got me a very significant performance boost in testing. Now I wonder why anyone would use synchronized since it is so much slower... is there a reason on modern 64 bit multi-core hardware? Others are asking me about Atomics now. I would love to be able to tell them to never use that keyword unless they are deploying to ancient hardware.

Answer 1

Because you can't do multiple actions exclusively using only atomics (well, technically you can, because you can implement a "lock" using atomics, but i think that's beside the point). you also can't do a blocking wait using atomics (you can do a busy wait, but that's almost always a bad idea).

here's an exercise for the OP: write a program which writes timestamped log messages using multiple threads to the same file where the messages must show up in the file in timestamp order. implement this using only atomics, but without re-inventing ReentrantLock/synchronized.

Answer 2

Now I wonder why anyone would use synchronized since it is so much slower...

Maybe because speed isn't everything.

In fact, if you looked objectively at the overall performance benefit of using your "nifty" generator on a real application, I suspect you will find that it is too small to matter. Profiling the application will tell you that.

Then there is the issue of whether your benchmarking is actually valid; i.e. whether you are doing the things that are needed to avoid misleading effects like JVM warmup anomalies, optimization anomalies, and so on. And whether you are (actually) measuring the contended and uncontended cases.

---

Is there a viable use case where Java synchronized keyword is better than Atomics?

That's easy.

Any situation where you require exclusive access to one or more data structures to perform a sequence of operations, or an operation that is not intrinsically thread-safe. The AtomicXxx types don't support this kind of thing.

---

I would love to be able to tell them to never use that keyword unless they are deploying to ancient hardware.

Don't tell them that. It is incorrect. In fact, if you are new to Java threads, I recommend that you read "Java Concurrency in Practice" by Goetz et al before you start advising people.

Answer 3

Depends on what you are doing - if you only need the functionality that an atomic provides you, then yes, there would be no need to do the same work yourself (using the synchronized keyword). However, many multithreaded applications do things a lot more complicated than just needing increment a number atomically.

For example, you might need a unit of work to be done where you modify several data structures in memory and all of that has to happen without interference - you could use a synchronized function or block for that.

Answer 4

From what I understand, the synchronized keyword is actually a moderately heavyweight recursive (re-entrant) lock.

For instance, the following (horrible) code would not deadlock:

public static Object lock = new Object();

int recurCount = 0;

public int fLocktorial(int n) {
    synchronized(lock) {
        recurCount++;
        if (n <= 0)
            return 1;
        return n * fLocktorial(n-1);
    }
}

Implementing this requires the maintenance of additional state and logic within the lock, which may contribute to its lower performance over atomics and other primitives. However, it does allow you to grab locks arbitrarily inside functions, without worrying if a caller has already obtained the lock. Locks implemented naively using Atomics would deadlock in this case.

Additionally, synchronized may yield performance benefits if large amounts of processing are done within the lock. Getting a lock only has a performance hit once, while atomics force a core synchronization per operation. This flushes the processor pipeline, impacting performance.

Answer 5

Conceptually, a critical section protected by a lock transform state from one valid state to another.

int x, y;  // invariant: x==y

void inc()
    synchronized(lock)
        x++;
        y++;

void dec()
    ...

We could encapsulate the state in an object, and atomically change the object.

class State
    final int x, y;
    State(int x, y) { ... }

volatile State state;

void inc()
    do
        State s = state;
        State s2 = new State(s.x+1, s.y+1);
    while( ! compareAndSet( "state", s, s2) )  // use Unsafe or something

Is that better? not necessarily. It is appealing, and it's simpler when states get more complicated; but it's probably slower in most cases.