double-checked-locking

I saw some examples in java where they do synchronization on a block of code to change some variable while that variable was declared volatile originally .. I saw that in an example of singleton class where they declared the unique instance as volatile and they sychronized the block that initializes that instance ... My question is why we declare it volatile while we synch on it, why we need to do both?? isn't one of them is sufficient for the other ?? public class someClass { volatile static uniqueInstance = null; public static someClass getInstance() { if(uniqueInstance == null) {

Back to concurrency. By now it is clear that for the double checked locking to work the variable needs to be declared as volatile . But then what if double checked locking is used as below. class Test<A, B> { private final Map<A, B> map = new HashMap<>(); public B fetch(A key, Function<A, B> loader) { B value = map.get(key); if (value == null) { synchronized (this) { value = map.get(key); if (value == null) { value = loader.apply(key); map.put(key, value); } } } return value; } } Why does it really have to be a ConcurrentHashMap and not a regular HashMap ? All map modification is done within

In the examples mentioned for Out-of-order writes for double-checked locking scenarios (ref: IBM article & Wikipedia Article ) I could not understand the simple reason of why Thread1 would come of out synchronized block before the constructor is fully initialized. As per my understanding, creating "new" and the calling constructor should execute in-sequence and the synchronized lock should not be release till all the work in not completed. Please let me know what I am missing here. The constructor can have completed - but that doesn't mean that all the writes involved within that constructor

In C++ and the Perils of Double-Checked Locking , there's persudo code to implement the pattern correctly which is suggested by the authors. See below, Singleton* Singleton::instance () { Singleton* tmp = pInstance; ... // insert memory barrier (1) if (tmp == 0) { Lock lock; tmp = pInstance; if (tmp == 0) { tmp = new Singleton; ... // insert memory barrier (2) pInstance = tmp; } } return tmp; } I just wonder that whether the first memory barrier can be moved right above the return statement? EDIT : Another question: In the linked article, as vidstige quoted Technically, you don’t need full

Given that string s contain final field, does it mean in the context of double checked locking it is not necessary to declare them volatile ? E.g. class SomeClass{ private String val; String getVal(){ if(val == null){ synchronized(this){ if(val ==null) val = new String("foo"); } } } } I used a string as an example, but it should work with other objects that declare some final field, correct? For strings you're right. A string which is declared final cannot be differed and therefore you do not need to synchronize when using it. Thats not true for other Objects. Take this little class for

I've got a web application where people ask for resources. This resources are cached using a synchronized hash map for efficiency. The problem here is when two different requests come for the same uncached resource at the same time: the operation retrieving the resources takes up a lot of memory, so I want to avoid calling it more than once for the same resource. Can somebody please tell me if there is any potential problem with the following snippet? Thanks in advance. private Map<String, Resource> resources = Collections.synchronizedMap(new HashMap<String, Resource>()); public void request

So I've seen a lot of articles now claiming that on C++ double checked locking, commonly used to prevent multiple threads from trying to initialize a lazily created singleton, is broken. Normal double checked locking code reads like this: class singleton { private: singleton(); // private constructor so users must call instance() static boost::mutex _init_mutex; public: static singleton & instance() { static singleton* instance; if(!instance) { boost::mutex::scoped_lock lock(_init_mutex); if(!instance) instance = new singleton; } return *instance; } }; The problem apparently is the line