Having some line of statements, is there a simple way to assure it is executed in atomic way?
-
3Define what exactly you mean by "atomic" here. – NPE Apr 13 '11 at 06:06
-
In most cases yes, in some cases no. Define your 'line of statements'. – david.pfx Jun 22 '14 at 09:58
-
Yes. Look here https://stackoverflow.com/a/16906229/715269 – Gangnus May 05 '19 at 14:39
5 Answers
Atomic? No. Despite what people are saying here, thread-safe doesn't mean atomic:
// this is NOT atomic!
synchronized(this) {
makeChangeA();
makeChangeB();
}
if makeChangeB() throws an exception, makeChangeA() will not rollback it's change.
Definition of atomic is "executed either completely, or not at all". Synchronized block is not atomic.

- 18,130
- 10
- 48
- 62
-
As much as I hate to agree, you're right, I glossed over the meaning. :-) +1 – user541686 Apr 13 '11 at 06:10
-
2But this is not the complete/total definition of atomic. In databases atomic is only this - in parallel computing atomic also means uninterruptible from other threads/process/code that access (read/write) the same data. So synchronized deals at least with 50% of the necessary stuff for atomic. For the all successfull/fail property the programmer has to do its own work - if there are exceptions he has to deal with them in his exception handler doing the rollback. – flolo Apr 13 '11 at 06:11
-
Same as in java: there no built-in support for atomic code blocks. Protection from access is isolation, btw. 'I' in ACID. – Vladimir Dyuzhev Apr 13 '11 at 06:15
-
1Don't agree. You're definition is true for "atomic" in a database context but the actual context is java. And here, [atomic operations](http://download.oracle.com/javase/tutorial/essential/concurrency/atomicvars.html) are just *not interruptable* (which is somewhat equivalent to being executed completely - when called - or not at all - if not called) - rollback of failed executions is *not* a requirement. – Andreas Dolk Apr 13 '11 at 06:19
-
But only in database context. In parallel execution atomic operations far more essential property is that it does not interfere with other operations, and the isolation is part (or better intention) of it. – flolo Apr 13 '11 at 06:21
-
And, BTW - you provide a definition for "Atomicity (Database Systems)", not for "[atomic](http://en.wiktionary.org/wiki/atomic)". – Andreas Dolk Apr 13 '11 at 06:23
-
Please provide an authoritative source that gives "atomic" any other definition but "all or nothing". That definition in turn requires some sort of rollback in case of partially completed transaction. – Vladimir Dyuzhev Apr 13 '11 at 06:25
-
@flolo In atomic instructions being uninterruptable is a WAY to achieve atomicity. Being uninterruptable is not required for atomicity. Another thread can "peek" into my data, can even change it -- but if I have a backup of my data, I can restore them on rollback. – Vladimir Dyuzhev Apr 13 '11 at 06:29
-
@road to yamburg: you are right, i have overseen then all or nothing semantic of atomic in this use case – Ralph Apr 13 '11 at 07:07
If your emphasis is on "simple way", you can try out the @Synchronized annotation of Project Lombok.

- 21,619
- 17
- 70
- 86
-
Wait, why do you need that? Can't you just say `synchronized void foo()` and have it do the same thing? – user541686 Apr 13 '11 at 05:55
-
@Mehrdad: if you look at the example, it is different form `synchronized void foo()`, it is more like `void foo() {synchronized(x){...}}` -- Anyway I agree with you. – Ralph Apr 13 '11 at 05:59
-
1Mehrdad, no. putting synchronized in the method signature synchronizes on `this`. Whereas Project Lombok locks on a generated object. The differences are subtle but important. – Joel Apr 13 '11 at 05:59
-
@Joel: Oh shoot, yeah I know the difference but I didn't notice the annotation can sync on a different object; interesting. – user541686 Apr 13 '11 at 06:05
synchronized (obj)
{
//any other thread synchronizing against obj waits until this block is done
}
Edit:
As road to yamburg mentioned, this is not atomicity; I had assumed you simply wanted to ensure that two blocks do not overlap in execution. If in fact you are looking for an atomic action, then you need to employ the user of transactions, which are by no means easy. See Atomicity and Transaction Processing for more info.
Furthermore, if you're guaranteeing atomicity, chances are you're also looking for consistency, isolation, and durability, collectively known as the ACID properties. These are also explained on the second page in detail.

- 205,094
- 128
- 528
- 886
As mentioned by others, synchronized does not provide true atomicity. However, it depends on what you want to achieve? If you’re interested in mutual exclusion only, than a synchronized block may help you very well.
Some atomic operations, however, are possible. Have a look at the package java.util.concurrent.atomic, which, for example, provides atomicIntegers which may be incremented atomically and retrieved in one step.
Otherwise you’ll need to implement your own solution, like with Semaphors which halt all other threads. But note, that even if you achieve to to block all other threads of your process their might as well other processes which interfere with what you are doing (I’m speaking of other OS processes, not only those running at the JVM).
But truly, what do you want to achieve? I’m pretty sure most daily use cases can be be tackled with synchronized blocks / methods and/or the mentioned atomic-pacakge.

- 11,904
- 14
- 72
- 127
-
There is a lot of usage for atomic blocks, and we all would use them a lot if they were available in JVM. But they are not, alas. – Vladimir Dyuzhev Apr 13 '11 at 06:32
put them in a synchronized
block, then it is atomic for the JVM.
public class MyClass {
//the English word is synchronizer, not syncronisator
private static final Object syncronisator = new Object();
public void doSomething() {
doSomethingNotSyncronized();
synchronized(syncronisator) {
doItAtomic1():
doItAtomic2():
}
doSomethingNotSyncronized2();
}
}
BTW: if you want to synchronize the complete method with the instance of MyClass, then you could use:
public class MyClass {
public void synchronized doSomething() {
doItAtomic1():
doItAtomic2():
}
}
Edit: Road to yamburg is right, atomic is not only synchronization, but mean also everything or none.
-
1AFAIK, the `doItAtomic` methods need to be synchronized on the same object - otherwise they could be called directly from a different thread and it wouldn't be "atomic" anymore. – Andreas Dolk Apr 13 '11 at 05:52
-
I believe the English word is `synchronizer`, not `syncronisator`. ;) – user541686 Apr 13 '11 at 05:54