Question whether a problem with race conditions exists in this case

I have a class Node as displayed below that holds a new value and the
previous value. Which one applies is determined by the value of
useNewValue. In my application there is a list of such nodes where for
each node the current value is replaced with a new one. The new values
should become effective for the entire list all >at once< through an
atomic change of useNewValue in every node. For that purpose, when the
new value is set, for every node in the list the same AtomicBoolean
instance is passed on to setNewValue(...), which is stored in
useNewValueParam. When the commit is done, the value of this instance
of AtomicBoolean is changed to true (this way the thread doing the
commit does not have to enter the synchronized block as all the other
threads calling aNode.get) and thus the new value of every node
becomes visible at once to every thread calling aNode.get().

public class Node {

    AtomicBoolean useNewValue = new AtomicBoolean(false);
    private Object newValue = null;
    private Object previousValue = null;
    private Object lock = new Object();

    public Object get() {
        synchronized(lock) {
            if(useNewValue.get()) // 1
                return newValue; // 2
            return previousValue; // 3
        }
    }

    public void setNewValue(Object newValue, AtomicBoolean
useNewValueParam) {
        synchronized(lock) {
            if(this.useNewValue.get())
                previousValue = this.newValue;
            this.newValue = newValue;
            // useNewValueParam is allways set to false when setNewValue is
called
            this.useNewValue = useNewValueParam;
        }
    }
}

At the same time there is never more than one thread iterating over
the node list calling setNewValue. This is made sure through
serialization of threads that want to iterate over the list calling
setNewValue. Serialization of threads is a bit crude, but not relevant
at the moment for the discussion of the problem described here.

My question is now whether this approach is free of race conditions or
starvation issues if implemented as described above. I have some
doubts whether everything is fine here as useNewValue is changed by
the commit thread by reference without entering synchronized(lock)
{ ... }. So is everything still fine if a context switch happens
between line 1 and 2 or between line 1 and 3? It would be for sure if
the commit thread entered the synchronized(lock) { ... } block, but it
does not (changing to the new values all at once wouldn't be possible
otherwise).

I would be thankful if someone could look over this and tell me her/
his opinion.

Thanks al lot, Oliver