[concurrency-interest] Immutable object conundrums

Jeremy Manson jeremy.manson at gmail.com
Wed Jul 1 00:37:42 EDT 2009


Sigh.  This is true, but they happen to be unnecessary on x86 +
hotspot.  It's an ongoing discussion.

Jeremy

On Tue, Jun 30, 2009 at 1:32 PM, Peter Veentjer<alarmnummer at gmail.com> wrote:
> 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