Home arrow C++ arrow Page 3 - C++ in Theory: Why the Double Check Lock Pattern Isn`t 100% Thread Safe
C++

C++ in Theory: Why the Double Check Lock Pattern Isn`t 100% Thread Safe


Back in January, Jun Nakamura discussed Singletons in a series of three articles, and revisited the subject in May. In the May article, he described the Double Checked Locking Pattern as a way to make Singletons thread safe. Unfortunately, it's not that simple, as he explains in this article.

Author Info:
By: J. Nakamura
Rating: 4 stars4 stars4 stars4 stars4 stars / 18
August 01, 2005
TABLE OF CONTENTS:
  1. · C++ in Theory: Why the Double Check Lock Pattern Isn`t 100% Thread Safe
  2. · The Original Problem
  3. · The Double Checked Locking Pattern
  4. · Object Creation
  5. · Multiprocessor Machines
  6. · Portable Solutions

print this article
SEARCH DEVARTICLES

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).


blog comments powered by Disqus
C++ ARTICLES

- Intel Threading Building Blocks
- Threading Building Blocks with C++
- Video Memory Programming in Text Mode
- More Tricks to Gain Speed in Programming Con...
- Easy and Efficient Programming for Contests
- Preparing For Programming Contests
- Programming Contests: Why Bother?
- Polymorphism in C++
- Overview of Virtual Functions
- Inheritance in C++
- Extending the Basic Streams in C++
- Using Stringstreams in C++
- Custom Stream Manipulation in C++
- General Stream Manipulation in C++
- Serialize Your Class into Streams in C++

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials