[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Vitaly Davidovich vitalyd at gmail.com
Mon Nov 28 10:10:42 EST 2011


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.
On Nov 28, 2011 10:01 AM, "Rémi Forax" <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>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
> 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/541dc522/attachment.html>


More information about the Concurrency-interest mailing list