[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Vitaly Davidovich vitalyd at gmail.com
Mon Nov 28 11:44:16 EST 2011


I don't have strong feelings on this as I wouldn't be the one making the
change :), but my point is that this functionality *is* available for the
rare occasion that it's needed, it's just "harder" to get at and discover
than if it were in j.l.Thread (or similar).  Since it's available (unless a
sec mgr prevents reflection) I personally don't see a good reason to move
it to a common JDK class to support broken code.
On Nov 28, 2011 11:04 AM, "Gregg Wonderly" <gregg at cytetech.com> wrote:

> 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.
>
> Gregg
>
>  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<Concurrency-interest at cs.oswego.edu><mailto:
>> Concurrency-interest@**cs.oswego.edu <Concurrency-interest at cs.oswego.edu>
>> >
>>    http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>
>>
>>
>> ______________________________**_________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111128/1cc7f5f7/attachment-0001.html>


More information about the Concurrency-interest mailing list