[concurrency-interest] memory barriers
Thu, 29 Jan 2004 04:43:16 -0800
Kasper Nielsen writes:
> Does it really need to be the _same_ synchronization lock?
Yup. (Depending on how optimal the JVM is...)
> They have something similar [MemoryBarrier] on the .NET platform
Interesting. If JMM achieves its goals then correctly synchronized Java
code will not only be more readable but will also soundly outperform .NET
code on multiprocessor Itaniums.
----- Original Message -----
From: "Kasper Nielsen" <email@example.com>
Sent: Thursday, January 29, 2004 3:53 AM
Subject: Re: [concurrency-interest] memory barriers
Joseph Bowbeer wrote:
> Kasper Nielsen asks:
>>print(foo.i) might write 4?
> In your example, the same thread that constructs foo also calls
> helper.print(foo), so the answer will always be 5. Inside a single
> program order rules.
oops I meant something like (too early in the morning)
print(i) //might read 4??
1. some thread calls fooMethod()
2. some other threads calls print() (but after fooMethod() has returned)
The question was really if the statement
Changes to fields made by one thread are guaranteed to be visible to
other threads only under the following conditions:
A writing thread releases a synchronization lock and a reading thread
subsequently acquires that _same_ synchronization lock.
do it really need to be the _same_ synchronization lock?
> The JMM spec is unclear about memory barriers so they can removed when it
> determined they are not needed. (In addition, memory barriers per se may
> not exist on some platforms.)
They have something similar on the .NET platform