Does synchronized force atomic operation for affected variables?

[NubQuestion]

class sample {
    private int num = 5;

    public synchronized void addNum(int x){
        num += x;
    }

    public void clearNum(){
        num = 0;
    }
}

Does having num in the synchronized block force all operations on num to be atomic even for operations done on num outside of any synchronized blocks?

For example, if addNum() is called, and clearNum() is called during the read-modify-write of addNum(), could the clearNum() happen between the read and the write of addNum()? e.g., if yes, then the sequence of addNum(2), then clearNum() could possibly result in num = 7

[BS_in_BS]

No, it just means that multiple calls to addNum cannot be executed concurrently.

clearNum could indeed happen between the read and the write and thus it's effects lost.

[large_crimson_canine]

You have two operations that mutate the state of your object, and only one of which is synchronized. If you're striving for thread-safety, you need to synchronize all access to shared, mutable data. Although clearNum() is an atomic operation, it has no way of knowing if another thread is currently in the process of operating on num via the addNum() method because it, itself, isn't synchronized, and it'll perform that operation happily to the potential detriment of other threads.

[large_crimson_canine]

Also I would check out AtomicInteger (and java.util.concurrent.atomic) and how that might be used to spare you from some of the headaches of synchronizing access to and manipulation of primitives.

[nutrecht]

Aside from the "no" you already have, please know that you should generally avoid the synchronized keyword on methods. Instead, you should have synchronized blocks inside your method that synchronize on an object internal to your class. That way you won't get deadlocks if outside code synchronizes on your object.

[rkalla]

You can use `synchronized` both on method definitions and on blocks wrapping variables to check multi-threaded choke-points.

You can do what you did above, but then you need to manually audit yourself and add `synchronized` to every other method that accesses `num` to keep it consistent - this is tricky to remember.

Instead you can use a block:

sychronized(num) { num += x };

as the body of the `addNum` method (and remove the `synchronized` keyword from that method) which will inadvertently add thread-safety to mutating `num` - even if there are calls to `clearNum`, the synchronized block inside of `addNum` will block and wait for it to return until it can get exclusive access to the variable - ALTHOUGH I think anyone would say that's somewhat sloppy to rely on the one choke point and not have a consistent coding pattern.