Re: Memory Model (yeah, this again...)

Who starts the new threads that read the field?
If all these new threads are started by the thread that
fills the HashMap and writes the field, then all the writes
"happen-before" the reads of the field and its data.
See JLS 17.4.4 and 17.4.5. Even without 'synchronized'
and 'volatile', the new threads will never see a stale value
in that field or a partially filled HashMap (assuming that
the HashMap is filled *before* the new threads are started).

If the new threads are *not* started by the thread that
fills the HashMap and writes the field, there are no
guarantees at all. Without 'synchronized' and/or 'volatile',
everything is possible - stale value, partially filled
HashMap...


Christopher

On Thu, Nov 20, 2008 at 14:33, Ken Gentle <[email protected]> wrote:
> I have a debate going on StackOverflow over an answer to this question:
>
> http://stackoverflow.com/questions/300316/java-concurrency-scenario-do-i-need-synchronization-or-not#300394
>
> I'm 'Ken G' in that forum.
>
> My understanding of the problem/question:
>
> 1) A Single instance of a class with an instance variable (heap, IIRC) that is a reference to a HashMap - private visibility, not volatile.
> 2) Multiple threads containing "readers" that get the value of the HashMap reference via an unsynchronized accessor method .  Threads exit, new threads get a HashMap reference as part of their startup via the method
> 3) The application refreshes with a new HashMap reference on some periodic basis.
> 4) It is OK if existing reader threads have references to an "old" HashMap as long as new threads get the reference to the "newest" HashMap.
>
> Given those conditions, my understanding is that no synchronization is required for *new* reader threads to pick up the most recent value of the HashMap reference.  With #4, there is no added value by synchronization or declaring the private, defining reference "volatile".
>
> The dissenting opinion is that "volatile" is required (or some other barrier) to force the *application's* copy of the reference to be visible to other threads.
>
> We've both been through section 17, and either we're not understanding it or we're not agreeing on the requirement.
>
> Would ya'll please take a look and point out if/where we're incorrect?
>
> ===================================
> View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives
>

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives