[concurrency-interest] Immutable object conundrums

Jeremy Manson jeremy.manson at gmail.com
Tue Jun 30 16:23:54 EDT 2009


On Tue, Jun 30, 2009 at 5:25 AM, Peter Veentjer<alarmnummer at gmail.com> wrote:
>> It seems to me that immutability for the sake of propagating constructor
>> changes to main memory
>> is something of a misnomer - this is more about using the 'final' keyword as
>> a coarse grained hook into the
>> java memory model. Maybe if we had more direct access to that memory model
>> then we could ensure
>> that mutable objects could safely be constructed as well, for example:
>>
>> public class MyMutableClass {
>>   private String myNonFinal;
>>
>>   public MyClass() {
>>      this.myNonFinal = "hello world";
>>      MemoryModel.flush(); // flush-commit similar to other cache
>> technologies
>>   }
>> }
>
> I don't see a happens before relation between the write of the
> myNonFinal example and the usage. So I don't think this example is
> going to work.

I think he was trying to express that the implicit relationship
between the write of a final and its reads is enforced by this API.
Something like this may be in the Fences API in Java 7.

Jeremy



More information about the Concurrency-interest mailing list