Library Solution possible? (was: Nice to @Share?)

Gernot Neppert mcnepp02 at googlemail.com
Tue Feb 23 02:46:03 PST 2010


2010/2/23 Reinier Zwitserloot <reinier at zwitserloot.com>:
> Sure. It already exists though:
> java.util.concurrent.atomic.AtomicReference<V>.
> Yes, you get the extra 'baggage' of the thread safety in the .get() and
> .set() methods that AtomicReference has, but this would seem to be a good
> thing, given that by sharing across lambdas you open the door to threading
> issues. On the other hand, past experiences in java have always resulted in
> creating a mirror non-thread-safe object (StringBuilder vs. StringBuffer,
> ArrayList vs. Vector, HashMap vs. Hashtable), for performance reasons.
> I always use AtomicReference (or AtomicInteger and variants) when I need
> mutable access to parent scope from an anonymous inner class literal.
> --Reinier Zwitserloot

Oh dear, of course you're right: java.util.concurrent.atomic already
contains the classes that I was proposing!

Don't know how that could have escaped me...

I don't think we'd need another family of non-thread-safe classes,
since the performance overhead should be neglible, especially if only
"get" and "set" would be used.


More information about the lambda-dev mailing list