[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Gregg Wonderly gregg at cytetech.com
Mon Nov 28 11:01:34 EST 2011

On 11/28/2011 9:10 AM, Vitaly Davidovich wrote:
> Difference is that locks were designed with tryXXX upfront whereas synch block
> was not, as David pointed out its missing some things.  Therefore, what you're
> proposing would encourage (or at least not discourage) a feature that wasn't
> meant for wide public consumption, irrespective if it's "safe" or not.

IDEs warn about the use of Object.wait() in loops because the can create 
"forever" problems.  Object.wait(int) is always suggested, just to wake up the 
thread and attempt forward progress.

As a general rule of thumb, "polling for completion", is something that Java 
APIs have done quite pervasively, and in this day and age, the call back model 
is often a better choice because it provides thread context control to the 
calling thread so that the person writing the called code doesn't have to know 
what thread context applies.

Providing these methods, for me, just maintains the "polling" mentality, but can 
also provide some relief for developers having to deal with this kind of 
"broken" code.  Like lock()/trylock()/unlock(), it does create the ability for 
developers to make errors in how locking is applied if they miss an exit from a 
lock()/trylock() environment and thus miss the unlock().  But, I think that is a 
small pill to swallow compared to having to "give up" because some old crufty 
code is "polling" for completion status.


> On Nov 28, 2011 10:01 AM, "Rémi Forax" <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
>     On 11/28/2011 03:35 PM, √iktor Ҡlang wrote:
>>     On Mon, Nov 28, 2011 at 3:24 PM, Vitaly Davidovich <vitalyd at gmail.com
>>     <mailto:vitalyd at gmail.com>> wrote:
>>         Relocating these methods to a "proper" JDK class will imply that it's
>>         ok to use them in normal operation, which I don't think is the case
>>         and hence, to me, unsafe sounds like the right place.
>>     It should probably be java.lang.Unsafe instead of sun.misc.Unsafe though
>     They are as unsafe as calling tryLock() and unlock() on a Lock,
>     so they can be in j.l.Thread as static methods.
>>         Why not have the 3rd party fix their code? I realize that won't help
>>         in the immediate situation, but that's actually the right solution here.
>>         $.02
>>         Vitaly
>     Rémi
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu <mailto: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