[concurrency-interest] Immutable object conundrums

Peter Veentjer alarmnummer at gmail.com
Tue Jun 30 16:32:14 EDT 2009


On Tue, Jun 30, 2009 at 10:23 PM, Jeremy Manson<jeremy.manson at gmail.com> wrote:
> 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

Hi Jeremy,

but you still need a store and load fence to guarantee a happens
before relation between the write and the read *in nitpicking mode*.

PS: Do you have a reference to the other concurrency features that are
going to be added (apart from the fences and the fork/join
functionality) to Java 7?



More information about the Concurrency-interest mailing list