Cheap read-write lock with hashmap

 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);
 
}

This is a code sample from this article https://www.ibm.com/developerworks/library/j-hashmap/index.html
I still don't understand why we need a synchronized block in buildNewMap method. What additional visibility guarantees it produces beside that volatile publishing at currentMap = newMap; does.
When we read map reference at m = currentMap; we rely upon volatile read-write and reading thread doesn't even know about syncronization in producer thread....

If the hashmap is only modified before it is written to the 'currentMap' its content is guaranteed to be visible to other threads. This is because there is a happens before edge between writing map content and writing to currentMap (program order); and there is a happens-before edge (volatile variable) between reading the concurrentMap, and there is a happens before edge between reading the variable and reading the content (program order). Since happens before is transitive, there is a happens beforge edge between writing the content and reading the content.

The synchronized block doesn't seem to serve any purpose.

Java memory model provides strong guarantees regarding volatile writes, according to this article:

http://tutorials.jenkov.com/java-concurrency/volatile.html

In particular:

> * If Thread A writes to a volatile variable and Thread B subsequently reads the same volatile variable, then all variables visible to Thread A before writing the volatile variable, will also be visible to Thread B after it has read the volatile variable.
> * If Thread A reads a volatile variable, then all all variables visible to Thread A when reading the volatile variable will also be re-read from main memory.

So it looks like the synchronized block is unnecessary.