C++ in Theory: Why the Double Check Lock Pattern Isn`t 100% Thread Safe - The Double Checked Locking Pattern
(Page 3 of 6 )
The creation of the Singleton has to be synchronized to make sure that only one Singleton can ever be created in a multithreaded environment. We would also like to acquire the needed lock for this synchronization only when the Singleton has not been created yet.
It is easy to make sure we won’t acquire the lock when it is not needed by checking whether our Singleton exists already or not; only when the pointer is 0 will we acquire the lock before we create the Singleton. It is still possible for a thread to be suspended immediately after the first check but before it receives the lock. Another thread might come in to get the lock and create the Singleton. When the lock is released, the first thread can acquire it and again it has to verify that the Singleton has not been created yet. This is the Double Checked Locking Pattern as conceived by Douglas Schmidt and Tim Harrison [Schmidt/Harrison]:
Singleton* Singleton::Instance() {
if (0 == pInstance) {
Guard lock(m_mutex);
if (0 == pInstance)
pInstance = new Singleton;
}
return pInstance;
}
You will probably look twice the first time you see this pattern applied, but it makes a lot of sense when you look closer. If thread A is suspended after the if statement but before acquiring a lock on the mutex, thread B can come in to acquire the lock and create the Singleton object. If thread B were to be suspended at any point during the creation, thread A will still have to wait for the release of the synchronization lock. The moment thread A resumes execution, pInstance won’t be 0 anymore and it won’t create a second instance of the Singleton.
Solved! Or is there a snake hiding in the grass? (This is a Dutch proverb. No pun towards Python was intended here).
Next: Object Creation >>
More C++ Articles
More By J. Nakamura
/ 12 
