The java.util.concurrent.atomic field updater classes only
guarantee volatile semantics and atomicity with regard to other
modifications using updaters.

Remove any hint that it cannot guarantee volatile semantics.
The underlying field is volatile, so "ordinary" access to
the field will have volatile semantics without any effort.

Regarding atomicity -- the atomicity may be dependent on a lock,
to which "ordinary" code is oblivious. However, atomicity fails
even when access to the field is done via a different updater
object, so add "on the same updater"