[concurrency-interest] Immutable object conundrums

Ashley Williams ashpublic at mac.com
Tue Jun 30 09:30:03 EDT 2009


Partial responses gratefully received.

Yes, I guessed CAS might be needed simply because the concepts from  
hibernate/jpa
seem to translate quite well to concurrency - optimistic locking in  
this case.

So I suppose in many situations I would also need to use a stamped  
reference
so that I could detect 'ABA' updates - and then some sort of conflict  
resolution
strategy to decide what to do when such a clash occurs.

As a corollary it looks like if you make an entity immutable then  
often you must make
references to it mutable, so for example in an entity relationship:

immutable child => mutable parent

On 30 Jun 2009, at 13:21, Jim Andreou wrote:

> This is a big one, I'll answer only in the question in the middle.
>
> 2009/6/30 Ashley Williams <ashpublic at mac.com>:
>>
>> Then I have to update the parent aggregate with the return value from
>> MyChild.modify(). But if ThreadA and ThreadB
>> both try to do this then I have to consider the possibility that  
>> one of the
>> updates will be overwritten by the other. So
>> rather than immutable objects being a silver bullet, I now appear  
>> to be
>> firmly in the territory of lost-updates,
>> unrepeatable reads and other isolation problems. Is this an  
>> inevitability,
>> or is there some other way people out there
>> are designing their way round this?
>>
>
> You need to atomically update the root reference to this structure
> (via cas). If a thread loses the race, it retries. This is a general
> technique that can transform any sequential structure to a lock-free
> one (described by Herlihy somewhere I think), but notice it can create
> lots of contention if updates are often and/or copying is slow, i.e.
> it doesn't really scale very well (as can be expected by a so
> generallly applicable technique).
>
> Dimitris



More information about the Concurrency-interest mailing list