[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

David Holmes davidcholmes at aapt.net.au
Sun Nov 27 23:23:05 EST 2011


Hanson Char writes:
> Performance aside, I find the use of Unsafe#tryMonitor{Enter,Exit}

tryExit ???

> extremely valuable in face of legacy code that uses synchronized
> block/method but the caller cannot afford to be "trapped" when calling
> the legacy code even when it entered into a indefinitely blocking
> state (within the synchronized block/method).

Can you expand on this. The only use case I can see is if you know the
legacy code will synchronize on a given instance and so you acquire it first
using tryLock. But that only protects you from the initial monitor
acquisition blocking indefinitely. This seems of very limited applicability.

> It would be really nice if the tryMonitor{Enter,Exit} can be promoted
> into a normal and safe jdk class for general use, so we don't need to
> use it in stealth mode.  Or maybe it already is in Java 7+ ?

There's no such proposal on the table at the moment. A tryLock without a
timed-variant is of limited use and monitors don't currently support
timed-acquisition, so there would be a bit of VM work to do - particularly
if you wanted it intrinisfied by the compilers.

Cheers,
David Holmes

> Regards,
> Hanson
>
> On Thu, Nov 17, 2011 at 3:26 AM, Roman Elizarov
> <elizarov at devexperts.com> wrote:
> > Unfortunately, I had to use Unsafe myself from time to time just for
> > performance reasons (because I have to write a lot of high-performance
> > code).
> >
> >
> >
> > /Roman
> >
> >
> >
> > From: Dr Heinz M. Kabutz [mailto:heinz at javaspecialists.eu]
> > Sent: Thursday, November 17, 2011 3:01 PM
> > To: Roman Elizarov
> > Cc: Martin Buchholz; concurrency-interest
> >
> > Subject: Re: [concurrency-interest] AtomicReferenceFieldUpdater
> vs Unsafe
> >
> >
> >
> > My thoughts exactly, Roman.  Us mere mortals figure out the "how to" by
> > reading JDK source code and when we see Unsafe being used, we
> go: "Ah, now
> > that's a good class to use..." ;-)
> >
> > From my newsletter:  http://www.javaspecialists.eu/archive/Issue194.html
> >
> > "In a recent email, one of my youngest readers, 17 year old Mr
> S.Perlov from
> > the Ukraine, suggested that I tell you about the class
> sun.misc.Unsafe. Up
> > to now I have avoided writing about it, as it is a class that should be
> > avoided. Here are two reasons: #1 it is "unsafe" and lets us do all the
> > nasty things that we had in C, such as pointer arithmetic or modifying
> > memory directly. #2 it is a sun.misc.* class. You do not know when that
> > might be renamed to oracle.misc.Unsafe or whether you will even run your
> > program on a Sun JVM. By binding yourself to a specific
> implementation of
> > the JVM, you are limiting the application of your code.
> >
> > Two reasons to not use Unsafe. I have personally never used Unsafe in
> > production code. Some experts do use it to write directly to memory.
> > Dangerous stuff! "
> >
> > Regards
> >
> >
> >
> > Heinz
> >
> > --
> >
> > Dr Heinz M. Kabutz (PhD CompSci)
> >
> > Author of "The Java(tm) Specialists' Newsletter"
> >
> > Sun Java Champion
> >
> > IEEE Certified Software Development Professional
> >
> > http://www.javaspecialists.eu
> >
> > Tel: +30 69 72 850 460
> >
> > Skype: kabutz
> >
> > On 11/17/11 12:53 PM, Roman Elizarov wrote:
> >
> > The downside is that it fuels the use of sun.misc.Unsafe by 3rd party
> > programmer. Every day there are more and more blogs explaining
> advantages of
> > Unsafe to the average programmer. I’ve just recently reposted
> one of those
> > for the Russian programmers community.
> >
> >
> >
> > Are there any concrete plans (say for Java 8) to bring the
> performance of
> > **Updater classes on par with Unsafe (maybe by improving
> HotSpot, so that it
> > can eliminate all the extra checks and compile **Updater method into the
> > same code as produced by direct use of Unsafe)? Shall we
> continue to rely on
> > Unsafe for Java 8 and beyond or get ready for its eventual
> elimination from
> > our codebase?
> >
> >
> >
> > Sincerely,
> >
> > Roman Elizarov
> >
> >
> >
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Martin
> > Buchholz
> > Sent: Thursday, November 17, 2011 3:45 AM
> > To: Dr Heinz M. Kabutz
> > Cc: concurrency-interest
> > Subject: Re: [concurrency-interest] AtomicReferenceFieldUpdater
> vs Unsafe
> >
> >
> >
> >
> >
> > On Wed, Nov 16, 2011 at 13:37, Dr Heinz M. Kabutz
> <heinz at javaspecialists.eu>
> > wrote:
> >
> > In Java 6, classes like ConcurrentLinkedQueue and
> SynchronousQueue used the
> > AtomicReferenceFieldUpdater to update the next, head, etc. fields.
> >
> > In Java 7, this was changed to instead use Unsafe.compareAndSwapObject()
> > directly.
> >
> > The AtomicReferenceFieldUpdater does a bunch of error checking
> every time it
> > is called, like this:
> >
> >           if (obj == null || obj.getClass() != tclass || cclass
> != null ||
> >               (update != null && vclass != null &&
> >                vclass != update.getClass()))
> >               updateCheck(obj, update);
> >           return unsafe.compareAndSwapObject(obj, offset,
> expect, update);
> >
> > My thinking is that the programmers changing ConcurrentLinkedQueue et al
> > probably wanted to improve the performance by not having to do all that
> > checking every time it is called.  The
> Unsafe.compareAndSwapObject() method
> > is probably compiled to a single CPU instruction.
> >
> > Is that correct?
> >
> > Yes.
> >
> >
> >
> > Is there any other reason for this change?
> >
> > The previous way was more principled, in the manner of "eat your own
> > dogfood".  Maybe we've become just a tiny bit less principled.
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>




More information about the Concurrency-interest mailing list