AtomicBoolean where is the lock?

Question

AtomicBoolean uses native code for synchronization. How does it translate into java locks?

what's the difference between:

AtomicBoolean a = new AtomicBoolean();
synchronized (a) {
   a.set(true);
}

vs:

a.set(true)

I know the synchronized(a) is not needed because a itself will ensure the operation is atomic. But is the lock in synchronized (a) the same lock as in a.set(true) ?

score 4 · Accepted Answer · answered Jul 02 '13 at 05:35

The atomic relies on the JVM for some if the atomicity, such as in set/get, but relies on the sun.misc.Unsafe class in other cases. You can check out the code at:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/concurrent/atomic/AtomicBoolean.java

It is also worth looking at:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/misc/Unsafe.java#Unsafe

which is used for lots of stuff in the JDK, although sadly it is not a public class. Made more sad because it is so obviously named that it could be public and completely "safe" to use ;-)

I should add, the whole idea of the atomic classes is to avoid locks and synchronization, which will often improve performance. You do not need to use locks to protect them, but may rely on operations like compareAndSwap or incrementAndGet (for numbers) that are not standard when you use a lock.

score 1 · Answer 2 · answered Jul 02 '13 at 05:41

1

No. AtomicBoolean, in fact, all of the atomic classes, use compare-and-swap to guarantee atomicitiy.

answered Jul 02 '13 at 05:41

Jeffrey

44,417
8
90
141

Yes, but is still different, it doesn't synchronize taking an object as lock, it uses an internal JVM instruction. – morgano Jul 02 '13 at 05:48
@mogano I never said it took an object as a lock. CAS is implemented via the `Unsafe` class with a `native` method. – Jeffrey Jul 02 '13 at 05:51
Granted, but I was focusing in the question at the end of the post (whether they were the same lock) – morgano Jul 02 '13 at 05:54

score 0 · Answer 3 · answered Jul 02 '13 at 05:38

this:

a.set(true);

isn't internally synchronized at all, have a look at the code of AtomicBoolean.java in JDK 1.7 (from src.zip):

/**
 * Unconditionally sets to the given value.
 *
 * @param newValue the new value
 */
public final void set(boolean newValue) {
    value = newValue ? 1 : 0;
}

so, yes, it is different to the synchronized version

score 0 · Answer 4 · answered Jul 04 '13 at 19:47

0

Synchronization keyword provide three guarantees according to JMM. 1. Atomicity 2. Visibility 3. Reordering

but synchronization is blocking in nature.

All the Atomic Classes in java like AtomicInteger, AtomicLong, AtomicBoolean etc also provide the above three guarantees. But they dont block other threads.

They Provide 1. Atomicity - by using compareAndSwap operation. 2. Visibility and Reordering - these are provide by declaring the underlying variable as volatile.

for example in AtomicInteger the underlying int variable is declared as volatile

private volatile int value;

answered Jul 04 '13 at 19:47

veritas

2,444
1
21
30

The primary "problem" with locking code is that a thread which gets waylaid between the time it acquires lock and the time it releases it may cause the progress of other threads to be blocked indefinitely. The `Atomic` classes guarantee that any hardware "lock" which is acquired during the operation will be released within a very short time *and nothing that might cause a thread to get waylaid can prevent that*. – supercat Jul 08 '13 at 21:35

AtomicBoolean where is the lock?

4 Answers4