atom feed19 messages in edu.oswego.cs.concurrency-interestRe: [concurrency-interest] The Atomic...
FromSent OnAttachments
David M. LloydJul 14, 2012 11:01 am 
Doug LeaJul 14, 2012 11:17 am 
Stanimir SimeonoffJul 14, 2012 1:01 pm 
√iktor ҠlangJul 14, 2012 1:16 pm 
Rémi ForaxJul 14, 2012 2:20 pm 
Stanimir SimeonoffJul 14, 2012 2:58 pm 
Rémi ForaxJul 14, 2012 3:44 pm 
Doug LeaJul 15, 2012 3:37 am 
David HolmesJul 15, 2012 4:14 am 
√iktor ҠlangJul 15, 2012 8:22 am 
David M. LloydJul 15, 2012 9:19 am 
Jed Wesley-SmithJul 15, 2012 7:31 pm 
David HolmesJul 15, 2012 7:35 pm 
David M. LloydJul 15, 2012 7:43 pm 
David HolmesJul 15, 2012 7:52 pm 
Jason T. GreeneJul 20, 2012 11:42 am 
David HolmesJul 20, 2012 6:34 pm 
David M. LloydJul 22, 2012 1:47 pm 
Doug LeaJul 23, 2012 3:44 am 
Subject:Re: [concurrency-interest] The Atomic*FieldUpdater situation
From:Stanimir Simeonoff (stan@riflexo.com)
Date:Jul 14, 2012 2:58:48 pm
List:edu.oswego.cs.concurrency-interest

The next question is how to guarantee that the update value as the right

type, otherwise you can corrupt the memory by putting a String in an Integer field (and you can't rely on generics for that).

Absolutely true, it's not needed to java.lang.Object, which is a start. C2 can eliminate redundant CHECKCAST since the class is a constant, dunno if Class.isAssignableFrom enjoys the same treatment. Hence, a simple class-gen will do the trick. Class-gen happen very often w/ reflect, so I do not consider it too special. Again, when System.ClassLoader is not present or the caller is from the bootstrap loader that class-gen can be omitted.

Since there would be a single subclass only instantiated in the JVM there

would be no performance loss from multi-site invocations.

You don't care if there are several subclasses because you've put your AtomicReferenceFieldUpdater in a static final field.

True that, it can be proven it won't change, even if it's an interface.

Stanimir