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.
