double-checked-locking

问题 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(

问题 After reading dozens of articles about DCL. I feel that I should not use this concept without volatile.If I will not lead this technique my code will not thread save and very very bad according one hundreed different reasons. Recently I reread basics Happens Before and I have a bit another view Lets research singleton code listing: public class Singleton{ private static Something instance = null; public static Singleton getInstance() { if (instance == null) { // point 1 synchronized

问题 The problems with the original Double-Checked Locking pattern have been well-documented: C++ and the Perils of Double-Checked Locking. I have seen the topic come up in questions on SO fairly often. I have come up with a version that, to me, seems to solve the race condition problem of the original pattern, but does it look ok to you? In the code below, I assume that LOCK is a properly implemented mutex type that causes a memory barrier at it's lock/unlock, and I don't attempt to deal with the

问题 I know that the common implementation of thread-safe singleton looks like this: Singleton* Singleton::instance() { if (pInstance == 0) { Lock lock; if (pInstance == 0) { Singleton* temp = new Singleton; // initialize to temp pInstance = temp; // assign temp to pInstance } } return pInstance; } But why they say that it is a thread-safe implementation? For example, the first thread can pass both tests on pInstance == 0 , create new Singleton and assign it to the temp pointer and then start

问题 Anything wrong with the following Singleton implementation? Foo& Instance() { if (foo) { return *foo; } else { scoped_lock lock(mutex); if (foo) { return *foo; } else { // Don't do foo = new Foo; // because that line *may* be a 2-step // process comprising (not necessarily in order) // 1) allocating memory, and // 2) actually constructing foo at that mem location. // If 1) happens before 2) and another thread // checks the foo pointer just before 2) happens, that // thread will see that foo

问题 This question already has answers here : Closed 8 years ago . Possible Duplicate: Double-checked locking in .net EDIT: lots of edits to clarify this question is not about singleton I find myself writing code like this: if(resourceOnDiskNeedsUpdating) { lock(lockObject) { if(resourceOnDiskNeedsUpdating) // has a previous thread already done this? UpdateResourceOnDisk(); } } return LoadResourceFromDisk(); UpdateResource() is a slow operation. Does this pattern make sense? Are there better

问题 I have the following code which could be called via multiple web-requests at the same second. As such, I don't want the second+ request hitting the database, but waiting until the first one does. Should I refactor this to use the Lazy<T> keyword class instead? If 10 calls to a Lazy<T> piece of code occur at the same time, do 9 of those calls wait for the first one to complete? public class ThemeService : IThemeService { private static readonly object SyncLock = new object(); private static

问题 I have the following code which could be called via multiple web-requests at the same second. As such, I don't want the second+ request hitting the database, but waiting until the first one does. Should I refactor this to use the Lazy<T> keyword class instead? If 10 calls to a Lazy<T> piece of code occur at the same time, do 9 of those calls wait for the first one to complete? public class ThemeService : IThemeService { private static readonly object SyncLock = new object(); private static

问题 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?

问题 I need to lazily initialize a map and its contents. I have the below code till now: class SomeClass { private Map<String, String> someMap = null; public String getValue(String key) { if (someMap == null) { synchronized(someMap) { someMap = new HashMap<String, String>(); // initialize the map contents by loading some data from the database. // possible for the map to be empty after this. } } return someMap.get(key); // the key might not exist even after initialization } } This is obviously not