[concurrency-interest] CPU cache-coherency's effects on visibility

Stanimir Simeonoff stanimir at riflexo.com
Thu Feb 14 12:38:55 EST 2013


this.shared can be hoisted by JVM unless it's volatile. So Thread1 always
sees the initial value, e.g. null.

The code can be x-formed into:
Thread 1:
Foo shared = this.shared
while (true){
    log(shared)
    Thread.sleep(1000L)
}


On Thu, Feb 14, 2013 at 6:48 PM, <thurston at nomagicsoftware.com> wrote:

> Given that all (?) modern CPUs provide cache-coherency, in the following
> (admittedly superficial example):
>
> Thread 1:
> while (true)
> {
>     log(this.shared)
>     Thread.sleep(1000L)
> }
>
> Thread 2:
>    this.shared = new Foo();
>
> with Thread 2's code only invoked once and sometime significantly after
> (in a wall-clock sense)
> Thread 1; and there are no operations performed by either thread forming a
> happens-before relationship (in the JMM sense).
>
> Is Thread 1 *guaranteed* to eventually see the write by Thread 2?
> And that that guarantee is provided not by the JMM, but by the
> cache-coherency of the CPUs?
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130214/d2510145/attachment.html>


More information about the Concurrency-interest mailing list