Agreeing with Peter. The map is local so it is safe until copied to
currentMap.

I think the idea here was to make sure the content of the map was correctly
published through synchronization.
As you correctly mentioned, the volatile causes a happens-before that makes
sure of that.

On Wed, 29 Jul 2020 at 03:05, Peter Veentjer <[email protected]> wrote:

> The volatile variable ensures that there is a happens-before edge between
> the write and the read.
>
> So the synchronized block isn't needed; it even doesn't provide any
> visibility guarantee because:
> - currentMap = newMap is not send in the synchronized block
> - currentMap isn't read in the synchronized block.
>
> I'm not completely sure what the purpose is of the synchronized block.
>
> Keep in mind that this article is of 2007. So it is pretty old.
>
> On Wed, Jul 29, 2020 at 9:57 AM SuperNunrg <[email protected]> wrote:
>
>> Hi experts,
>>
>> I found this article
>> https://www.ibm.com/developerworks/library/j-hashmap/index.html and
>> stuck upon that statement
>>
>> static volatile Map currentMap = null;   // this must be volatile
>> static Object lockbox = new Object();
>> public static void buildNewMap() {       // this is called by the
>> producer
>>     Map newMap = new HashMap();          // when the data needs to be
>> updated
>>     synchronized (lockbox) {                 // this must be
>> synchronized because of the Java memory model
>>       // .. do stuff to put things in newMap
>>       newMap.put(....);
>>       newMap.put(....);
>>    }
>> /* After the above synchronization block, everything that is in the
>> HashMap is visible outside this thread */
>>
>> /* Now make the updated set of values available to the consumer threads.
>> As long as this write operation can complete without being interrupted,
>>    and is guaranteed to be written to shared memory, and the consumer can
>> live with the out of date information temporarily, this should work fine */
>>
>>     currentMap = newMap;
>>
>> }
>> public static Object getFromCurrentMap(Object key) {
>>     Map m = null;
>>     Object result = null;
>>
>>     m = currentMap;               // no locking around this is required
>>     if (m != null) {              // should only be null during
>> initialization
>>       Object result = m.get(key); // get on a HashMap is not synchronized
>>
>>       // Do any additional processing needed using the result
>>     }
>>     return(result);
>> }
>>
>>
>> The synchronized block and the volatile keyword in Listing 1 are
>>> required because no happens-before relationship exists between the writes
>>> to the currentMap and the reads from currentMap.
>>
>>
>> I don't understand why we need a synchronized block in this case. isn't
>> it enough, in this case, to publish a newly created and populated hashmap
>> through a volatile variable to make other thread see its contents?
>>
>> Thanks in advance
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/337d1e27-b31f-4e57-a937-62929fad54a2o%40googlegroups.com
>> <https://groups.google.com/d/msgid/mechanical-sympathy/337d1e27-b31f-4e57-a937-62929fad54a2o%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCY1A2ErZJkp7ns7tuyq1UOcUJqA8QyUsrCMS5EzQ5UGA%40mail.gmail.com
> <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCY1A2ErZJkp7ns7tuyq1UOcUJqA8QyUsrCMS5EzQ5UGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CADZL2%3DvKRyyUQZzhbWp4X_W%2BUWpGTK76t%2B1fp2F1ZW8PtSYugA%40mail.gmail.com.

Reply via email to