[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
9 Jan 2004 21:34:24 -0000
> AtomicX classes [are designed / exist] to support unsynchronized
> concurrent modifications.
It seems evident to me that the Atomic* classes are a way for
the Java language/API to provide efficient access to whatever
"test-and-set", "compare-and-swap", "read-modify-write",
"fetch-and-store", etc, style operations are provided by the
CPUs of the host; they do not in and of themselves provide any
new basic functionality, just a potentially dramatic performance
optimization for cases where an entity/object is accessed often,
and there may be a thread which tries to change its state to a
different state based on its current state while other threads
are trying to access the object, and the semantics for deciding
to change the object state map sufficiently cleanly to the
underlying test-and-set paradigm.
> The comparable etc. exist for classes which are either immutable
> (from the comparison point of view) or at least with the
> mutability under control of the application (via either
> confinement or synchronization), so that the comparison results
> may be relied upon for some definite period of time. AtomicX
> have the exactly opposite intent: to facilitate concurrent
> modifications assuming lack of confinement or synchronization.
It looks to me like think AtomicX provide a specific simple case of
confinement/synchronization under the control of the application
which happens to map cleanly to instructions which can be performed
orders of magnitude more quickly by the JVM or CPU than if they were
implemented them using the Java language level equivalents. I do not
think they change the fundamental nature of the entities for which they
are providing that particular case of confinement/synchronization, or
that those entities which would benefit from the use of that efficient
implementation are necessarily inherently different in practice from
those which would not.
It think it makes sense for there to be a class which can perform
a sequence of operations efficiently, and I think it makes sense to
have an instance of that class which associates itself with a
particular entity on which it will be performing those operations.
I just do not like the idea in the case of AtomicX of imposing any
more semantic/logical/homological assumptions/constraints than are
made by, say, System.arraycopy(). "Mechanism, not policy", I
guess, makes sense to me when it comes to API design.