hg: lambda/lambda/jdk: Summary: add ThreadLocal(Factory<T>) and compareAndSet methods

[David Holmes]

On 31/07/2012 11:42 PM, Aleksey Shipilev wrote:
> On 07/31/2012 04:59 PM, Doug Lea wrote:
>> This accentuates the "moral hazard" issue I mentioned.
>> What is the motivation for incorporating into JDK convenience methods to
>> support a technique with such a restricted range of applicability?
>
> I would disagree about the "restricted" here. Any other way to have
> multi-site atomicity? My experience tells me, people faced with multiple
> updates would end up with locking, because "it feels cleaner" than to
> expose the loop in the code. Asking users to provide the updater is
> something we can do to lower that impedance.

Multi-site atomicity? What do you mean?

This is just a convenience function for the loop the user has to write 
today:

do {
   Value old = get();
   Value new = transform(old);
} while (!compareAndSet(old, new));

David
-----

>> On contention, this method will not only eat a lot of cycles but
>> also spew a lot  of garbage. Sometimes this is a good choice anyway.
>
> Even if this is abused, the CPU cycles spent in CAS'ed loop are easily
> detectable by whatever naive profiler you have. Locks, on the other
> hand, are notoriously hard to diagnose in full.
>
> -Aleksey.
>