C++ and the Perils of Double-Checked Locking

本文探讨了C++中Singleton模式的传统实现为何在多线程环境下存在缺陷,并深入分析了双检锁模式(DCLP)试图解决这些问题的方式及其在不同架构下可能遇到的问题。

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf


C++ and the Perils of Double-Checked Locking ∗

Scott Meyers and Andrei Alexandrescu
September 2004
Multithreading is just one damn thing after, before, or simultaneous
with another.
1 Introduction
Google the newsgroups or the web for the names of various design patterns,
and you’re sure to find that one of the most commonly mentioned is Singleton.
Try to put Singleton into practice, however, and you’re all but certain to bump
into a significant limitation: as traditionally implemented (and as we explain
below), Singleton isn’t thread-safe.
Much effort has been put into addressing this shortcoming. One of the most
popular approaches is a design pattern in its own right, the Double-Checked
Locking Pattern (DCLP) [13, 14]. DCLP is designed to add efficient threadsafety
to initialization of a shared resource (such as a Singleton), but it has a
problem: it’s not reliable. Furthermore, there’s virtually no portable way to
make it reliable in C++ (or in C) without substantively modifying the conventional
pattern implementation. To make matters even more interesting, DCLP
can fail for different reasons on uniprocessor and multiprocessor architectures.
This article explains why Singleton isn’t thread safe, how DCLP attempts to
address that problem, why DCLP may fail on both uni- and multiprocessor architectures,
and why you can’t (portably) do anything about it. Along the way,
it clarifies the relationships among statement ordering in source code, sequence
points, compiler and hardware optimizations, and the actual order of statement
execution. Finally, it concludes with some suggestions regarding how to add
thread-safety to Singleton (and similar constructs) such that the resulting code
is both reliable and efficient.
2 The Singleton Pattern and Multithreading
The traditional implementation of the Singleton Pattern [7] is based on making
a pointer point to a new object the first time the object is requested:
∗This is a slightly-modified version of an article that appeared in Dr. Dobbs Journal in
the July (Part I) and August (Part II), 2004, issues.
1
1 // from the header file
2 class Singleton {
3 public:
4 static Singleton* instance();
5 ...
6 private:
7 static Singleton* pInstance;
8 };
9
10 // from the implementation file
11 Singleton* Singleton::pInstance = 0;
12
13 Singleton* Singleton::instance() {
14 if (pInstance == 0) {
15
打开链接下载源码: https://pan.quark.cn/s/c43e5bd27521 标题中的“AMD and Nvidia GOP update 1.9.6.rar”表示这是一个包含了AMD与Nvidia显卡的GOP(Graphics Output Protocol)驱动程序升级至1.9.6版本的压缩文件。该更新主要针对显卡在UEFI(统一可扩展固件接口)环境下的图形输出性能进行优化,并致力于提升系统的稳定性。在描述中提及“显卡附加UEFI引导工具,最新版”,表明此次更新内含了一个专为UEFI BIOS环境设计的显卡引导工具,或许表现为一个自启动脚本或程序,例如GOPupd.bat。通过这一工具,用户能够在UEFI模式下对显卡进行精确的配置和初始化,从而保障操作系统能够最大化地发挥显卡的效能。必需的组件包括“colorama-0.4.3”,这是一个在Windows平台上用于管理颜色控制序列的Python模块,可能在更新过程中用于生成彩色命令行显示,以增强用户交互的直观性。此外,“Visual C++Redistributable”是微软提供的运行时支持库,旨在确保基于C++编译的应用程序能够正常运行,此处可能用于更新工具或相关依赖模块。标签“uefi bios”突显了该更新与UEFI BIOS系统的紧密关联,暗示其将作用于计算机的启动序列及硬件初始化过程。压缩包内的文件清单如下: 1. GOPupd.bat - 很有可能是负责执行GPU UEFI引导更新的核心脚本。 2. #Nvidia_ROM_Info.bat 和 #AMD_ROM_Info.bat - 这两个文档可能用于采集Nvidia与AMD显卡的ROM数据,以辅助识别显卡型号并执行适配性验证。 3....
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值