[concurrency-interest] backport: AtomicLongFieldUpdater support
dawidk at mathcs.emory.edu
Mon Dec 5 11:33:15 EST 2005
Moran Or Avigdor wrote:
> Thank you for your feedback.
> Isn't the reflection done only once per newUpdater call?
> If a LockedUpdater is supplied then the synchronization should work
> well for its implications.
> Although it is not correct to state that on JDK1.4 the underlying JVM
> doesn't supports lockless CompareAndSet for longs, but the
> effect will return the needed Updater.
> Am I missing something in my assesment?
> Am I correct to assume that the LockedUpdater should suffice?
I was thinking of something along the lines of the older JSR 166
but it requires, in the best case, two reflective calls
(Field.getLong/Field.setLong) per an operation. It may be interesting to
test that and see how much overhead that would cause (reflection has a
fast path for unchecked accessor methods), but Doug's comments suggest
that they've tried it and it was not good.
On the other hand, you're suggesting using sun.misc.Unsafe. This may be
quite an interesting idea. The backport already uses sun.misc.Perf for
microsecond-precision timer, if the class can be found, and otherwise
falling back to System.currentTimeMillis(). Maybe similar approach could
be taken for sun.misc.Unsafe?...
On the other hand, why do you need the field updater in the first place?
Chances are, you have a non-blocking algorithm that you want to port to
1.4. It is usually quite easy to modify such algorithms to use
synchronization instead of atomic field updaters. Example of this is
ConcurrentSkipListMap and some other classes in j.u.c. that I've
backported this way.
(Technically, the algorithm is non-blocking no more, but the locks are
held so briefly that it retains very high scalability, for the price of
higher single-thread execution overhead.)
More information about the Concurrency-interest