[concurrency-interest] Should I avoid compareAndSet with value-based classes?

Alex Otenko oleksandr.otenko at gmail.com
Wed Jul 12 06:44:59 EDT 2017


That shouldn’t be a problem for some well-behaving types. Immutable types certainly could behave like that - that’s the behaviour when there is a single instance for any value.

Since there is never a “direct” way to CAS values, it would be the job of the AtomicFieldUpdater to do “the right thing” for values that are such special values for which people struggle to formulate an uncontentious javadoc about its “==“ and its impact on CAS.

Alex

> On 12 Jul 2017, at 11:18, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> 
> 
>> On Jul 12, 2017, at 1:15 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>> 
>> As the author of Instant, what I would really like is for == to mean
>> .equals().
> 
> Really? There is a definitive semantic difference between == and equals() and I’m trying to sort out why anyone would want to confuse them.
> 
> Kind regards,
> Kirk
> 
> _______________________________________________
> 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