并行编程之多线程共享非volatile变量,会不会可能导致线程while死循环

简介:

背景

大家都知道线程之间共享变量要用volatile关键字。但是,如果不用volatile来标识,会不会导致线程死循环?比如下面的伪代码:

static int flag = -1;
void thread1(){
  while(flag > 0){
    //wait or do something
  }
}
void thread2(){
  //do something
  flag = -1;
}

线程1,线程2同时运行,线程2退出之后,线程1会不会有可能因为缓存等原因,一直死循环?

真实的世界

第一个坑:不靠谱的编绎器

直接上代码:

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

static int vvv = 1;
void* thread1(void *){
	sleep(2);
	printf("sss\n");
	vvv = -1;
	return NULL;
}
int main() {
	pthread_t t;
	int re = pthread_create(&t, NULL, &thread1, NULL);
	if(re < 0){
		perror("thread");
	}
	while(vvv > 0){
//		sleep(1);
	}
	return 0;
}

在main函数里启动了一个线程thread1,thread1会等待一段时间后修改vvv = -1,然后当vvv > 0时,主线程会一直while循环等待。

理想的情况下是这样的:

主线程死循环等待,2秒之后thread1输出"sss",thread1退出,主线程退出。


保存为thread-study.c 文件,直接用gcc -O3 优化:

gcc thread-study.c -O3  -pthread -gstabs
再执行 ./a.out,可以发现控制台输出“sss”之后,会一直等待,再查看CPU使用率,一个核跑满了,说明主线程在死循环。

貌似就像上面所的,主线程因为缓存的原因,导致读取的 vvv 变量一直是旧的,从而死循环了。

但是否真的如此?

经过测试,除了O0级别(即完全不优化)不死循环外,O1,O2,O3级别,都会死循环。

再查看下O3级别的汇编代码(用 gcc -S thread-study.c 生成),main函数部分是这样的:

为了便于查看,手动加了注释。

main:
.LFB56:
	.cfi_startproc
	subq	$24, %rsp
	.cfi_def_cfa_offset 32
	xorl	%ecx, %ecx
	xorl	%esi, %esi
	movl	$_Z7thread1Pv, %edx
	movq	%rsp, %rdi
	call	pthread_create                              //int re = pthread_create(&t, NULL, &thread1, NULL);
	testl	%eax, %eax
	js	.L9
.L4:
	movl	_ZL3vvv(%rip), %eax         //while(vvv > 0){
	testl	%eax, %eax
	jle	.L5
<strong>.L6:
	jmp	.L6</strong>
	.p2align 4,,10
	.p2align 3
.L5:
	xorl	%eax, %eax
	addq	$24, %rsp
	.cfi_remember_state
	.cfi_def_cfa_offset 8
	ret
.L9:
	.cfi_restore_state
	movl	$.LC1, %edi
	call	perror                               //perror("thread");
	jmp	.L4
	.cfi_endproc

在L6标号那里,比较奇怪:

.L6:
jmp .L6

这里明显就是死循环,根本没有去尝试读取xxx的值。那么L4那个标号又是怎么回事?L4的代码是读取 vvv 变量再判断。但是它为什么没有在循环里?

再用gdb从汇编调试下,发现主线程的确是执行了死循环:

   0x0000000000400609 <+25>:    mov    0x200a51(%rip),%eax        # 0x601060 <_ZL3vvv>
   0x000000000040060f <+31>:    test   %eax,%eax
   0x0000000000400611 <+33>:    jle    0x400618 <main+40>
<strong>=> 0x0000000000400613 <+35>:    jmp    0x400613 <main+35></strong>
   0x0000000000400615 <+37>:    nopl   (%rax)

一个jmp指令原地跳转,自然是一个死循环,正对应上面汇编代码的L6部分。

相当于生成了这样的代码:

	if(vvv > 0){
		goto return
	}
	for(;;){
	}

可见gcc生成的代码有问题,它根本就没有生成正确的汇编代码。尽管这种优化是符合规范的,但我个人比较反感这种严重违反直觉的优化。

那么我们的问题还没有解决,接下来修改汇编代码,让它真正的像这样所预期的那样工作。只要简单地把L6的jmp跳转到L4上:

.L4:
	movl	_ZL3vvv(%rip), %eax
	testl	%eax, %eax
	jle	.L5
.L6:
	jmp	.L4
	.p2align 4,,10
	.p2align 3
这个才我们真正预期的代码。

再测试下这个修改过后的代码:

gcc thread-study.s -o test -pthread -gstabs -O3
./test
执行2秒之后,退出了。

说明,主线程并没有一直读取到旧的共享变量的值,符合预期。

加上volatile

给" vvv "变量加上volatile,即:

volatile static int vvv = 1;

重新编绎后,再跑下,发现正常了,2秒后进程退出。

查看下汇编代码,是这样的:

.L5:
	movl	_ZL3vvv(%rip), %eax
	testl	%eax, %eax
	setg	%al
	testb	%al, %al
	jne	.L5
这段汇编代码符合预期。

但是这里还是有点不对,volatile的特殊性在哪里?生成的汇编没有什么特别的指令,那它是如何“防止”了线程不缓存共享变量的?

网上流传的一种说法是使用volatile关键字之后,读取数据一定从内存中读取。

这种说法既是对的,也是错的。volatile关键字防止了编绎器优化,所以对于变量不会被放到寄存器里,或者被优化掉。但是volatile并不能防止CPU从Cache中读取数据。

所谓的“缓存”到底是什么

CPU内部有寄存器,有各级Cache,L1,L2,L3。我们来考虑下到底怎样才会出现线程共享变量被放到CPU的寄存器或者各级Cache的情况。

volatile阻止了编绎器把变量放到寄存器里,那么对线程共享变量的读取即直接的内存访问。

CPU Cache

CPU Cache放的正是内存的数据,像

movl _ZL3vvv(%rip), %eax

这样的指令,是会先从CPU Cache里查找,如果没有的话,再通过总线到内存里读取。

而现代CPU有多核,通常来说每个核的L1, L2 Cache是不共享的,L3 Cache是共享的。

那么问题就变成了:线程A修改了Cache中的内容,线程B是否会一直读取到的都是旧数据?

MESI协议

既然Cache数据会不一致,那么自然要有个机制,让它们之间重回一致。经典的Cache一致性协议是MESI协议。

MESI协议是使用的是Write Back策略,即当一个核内的Cache更新了,它只修改自己核内部的,并不是同步修改到其它核上。

在MESI协议里,每行Cache Line可以有4种状态:

  • Modified     该Cache Line数据被修改,和内存中的不一致,数据只存储在本Cache Line里。
  • Exclusive   该Cache Line数据和内存中的一致,数据只存在本Cache Line里。
  • Shared       该Cache Line数据和内存中的一致,数据存在多个Cache Line里,随时会变成Invalid状态。
  • Invalid         该Cache Line数据无效(即不会再使用)

MESI协议里,状态的转换比较复杂,但是都和人的直觉一致。对于我们研究的问题而言,只需要知道:

当是Shared状态的时,修改Cache Line的内容前,要先通过Request For Ownership (RFO)的方式广播通知其它核,把Cache Line置为Invalid。

当是Modified状态时,Cache控制器会(snoop)拦截其它核对该Cache Line对应的内存地址的访问,在回应回插入当前Cache Line的数据。并把本Cache Line的内容回写到内存里,状态改为Shared。

因此,并不会存在一个核内的Cache数据修改了,另一个核没有感知的情况。

即不会出现线程A修改了Cache中的内容,线程B一直读取到的都是旧数据的情况。考虑到CPU内部通迅都是很快的,本人估计线程A修改了共享变量,线程B读取到新值的时间应该是纳秒级之内。

还有一个坑:CPU乱序执行

现代很多CPU都有乱序执行能力,从上面加了volatile之后生成的汇编代码来看,没有什么特别的地方。那么它对于CPU乱序执行也是无能为力的。比如:

volatile static int flag = -1;
void thread1(){
  ...
  jobA();
  flag = 1;
}
void thread2(){
  ...
  while(1){
    if(flag > 0)
      jobB();
  }
}

对于这两个线程,jobB()有可能比jobA()先执行!

因为thread1里,可能会因为CPU乱序执行,先执行了flag = 1,再执行jobA()。

那么如何防止这种情况?这个麻烦是CPU搞出来的,自然也是CPU提供的解决办法。

GCC内置了一些原子内存访问的函数,如:

http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Atomic-Builtins.html

type __sync_fetch_and_add (type *ptr, type value, ...)
type __sync_fetch_and_sub (type *ptr, type value, ...)
type __sync_fetch_and_or (type *ptr, type value, ...)
type __sync_fetch_and_and (type *ptr, type value, ...)
type __sync_fetch_and_xor (type *ptr, type value, ...)
type __sync_fetch_and_nand (type *ptr, type value, ...)

这些函数实际即隐含了memory barrier。

比如为之前讨论的代码加上memory barrier:

	while(true){
		__sync_fetch_and_add(&vvv,0);
		if(vvv < 0 )
			break;
	}
再查看下生成的汇编代码:

.L4:
	<strong>lock addl	$0, _ZL3vvv(%rip)</strong>
	movl	_ZL3vvv(%rip), %eax
	shrl	$31, %eax
	testb	%al, %al
	je	.L5
	jmp	.L8
.L5:
	jmp	.L4
可以看到,加多了一条 lock addl 的指令。

这个lock,实际上是一个指令前缀,它保证了当前操作的Cache Line是处于Exclusive状态,而且保证了指令的顺序性。这个指令有可能是通过锁总线来实现的,但是如果总线已经被锁住了,那么只会消耗后缀指令的时间。
实际上Java里的volatile就是在前面加了一个lock add指令实现的。这个有空再写。

其它的一些东东

有些场景可以不用volatile

抛开上面的讨论,其实有些场景可以不使用volatile,比如这种随机获取资源的代码:

ramdonArray[10];
int pos = 0;
Resource getResource(){
  return ramdonArray[pos++%10];
}

这样的代码pos是非volatile,但多线程调用getResource()函数完全没有问题。

C11与C++11

为什么C11和C++11不把volatile升级为java/C#那样的语义?我猜可能是所谓的“兼容性”问题。。蛋疼

C++11提供了Atomic相关的操作,语义和Java里的volatile差不多。但是C11仍然没有什么好的办法,貌似只能用GCC内置函数,或者写一些类似的汇编的宏了。

http://en.cppreference.com/w/cpp/atomic

GCC优化的一些东东

其实在讨论的代码里,如果while循环里多一些代码,GCC可能就分辨不出是否能优化了

优化的一些东东:

比如,在大部分语言里(特别是动态语言),第一份代码要比第二份代码要高效得多。

//1
int len = array.length;
for(int i = 0; i < len; ++i){
}
//2
for(int i = 0; i < array.length; ++i){
}


总结:

回到最初的问题:多线程共享非volatile变量,会不会可能导致线程while死循环?

其实这事要看很多别的东西的脸色。。编绎器的,CPU的,语言规范的。。

对于没有被编绎器优化掉的代码,CPU的Cache一致性协议(典型MESI)保证了,不会出现死循环的情况。这个不是volatile的功劳,这个只是CPU内部的正常机制而已。

对于多线程同步程序,要小心地在合适的地方加上内存屏障(memory barrier)。

参考:

http://en.wikipedia.org/wiki/Volatile_variable  

http://en.wikipedia.org/wiki/MESI

http://en.wikipedia.org/wiki/Write-back#WRITE-BACK

http://en.wikipedia.org/wiki/Bus_snooping

http://en.wikipedia.org/wiki/CPU_cache#Multi-level_caches

http://blog.jobbole.com/36263/     每个程序员都应该了解的 CPU 高速缓存

http://stackoverflow.com/questions/4232660/which-is-a-better-write-barrier-on-x86-lockaddl-or-xchgl

http://stackoverflow.com/questions/8891067/what-does-the-lock-instruction-mean-in-x86-assembly

http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Atomic-Builtins.html

http://en.cppreference.com/w/cpp/atomic

目录
相关文章
|
3月前
|
安全 算法 Java
Java 多线程:线程安全与同步控制的深度解析
本文介绍了 Java 多线程开发的关键技术,涵盖线程的创建与启动、线程安全问题及其解决方案,包括 synchronized 关键字、原子类和线程间通信机制。通过示例代码讲解了多线程编程中的常见问题与优化方法,帮助开发者提升程序性能与稳定性。
144 0
|
3月前
|
数据采集 监控 调度
干货分享“用 多线程 爬取数据”:单线程 + 协程的效率反超 3 倍,这才是 Python 异步的正确打开方式
在 Python 爬虫中,多线程因 GIL 和切换开销效率低下,而协程通过用户态调度实现高并发,大幅提升爬取效率。本文详解协程原理、实战对比多线程性能,并提供最佳实践,助你掌握异步爬虫核心技术。
|
4月前
|
Java 数据挖掘 调度
Java 多线程创建零基础入门新手指南:从零开始全面学习多线程创建方法
本文从零基础角度出发,深入浅出地讲解Java多线程的创建方式。内容涵盖继承`Thread`类、实现`Runnable`接口、使用`Callable`和`Future`接口以及线程池的创建与管理等核心知识点。通过代码示例与应用场景分析,帮助读者理解每种方式的特点及适用场景,理论结合实践,轻松掌握Java多线程编程 essentials。
250 5
|
8月前
|
Python
python3多线程中使用线程睡眠
本文详细介绍了Python3多线程编程中使用线程睡眠的基本方法和应用场景。通过 `time.sleep()`函数,可以使线程暂停执行一段指定的时间,从而控制线程的执行节奏。通过实际示例演示了如何在多线程中使用线程睡眠来实现计数器和下载器功能。希望本文能帮助您更好地理解和应用Python多线程编程,提高程序的并发能力和执行效率。
258 20
|
8月前
|
安全 Java C#
Unity多线程使用(线程池)
在C#中使用线程池需引用`System.Threading`。创建单个线程时,务必在Unity程序停止前关闭线程(如使用`Thread.Abort()`),否则可能导致崩溃。示例代码展示了如何创建和管理线程,确保在线程中执行任务并在主线程中处理结果。完整代码包括线程池队列、主线程检查及线程安全的操作队列管理,确保多线程操作的稳定性和安全性。
|
10月前
|
NoSQL Redis
单线程传奇Redis,为何引入多线程?
Redis 4.0 引入多线程支持,主要用于后台对象删除、处理阻塞命令和网络 I/O 等操作,以提高并发性和性能。尽管如此,Redis 仍保留单线程执行模型处理客户端请求,确保高效性和简单性。多线程仅用于优化后台任务,如异步删除过期对象和分担读写操作,从而提升整体性能。
161 1
|
10月前
|
Java 程序员 调度
【JavaEE】线程创建和终止,Thread类方法,变量捕获(7000字长文)
创建线程的五种方式,Thread常见方法(守护进程.setDaemon() ,isAlive),start和run方法的区别,如何提前终止一个线程,标志位,isinterrupted,变量捕获
|
12月前
|
Java 开发者
在Java多线程编程中,选择合适的线程创建方法至关重要
【10月更文挑战第20天】在Java多线程编程中,选择合适的线程创建方法至关重要。本文通过案例分析,探讨了继承Thread类和实现Runnable接口两种方法的优缺点及适用场景,帮助开发者做出明智的选择。
109 2
|
12月前
|
Java
Java中多线程编程的基本概念和创建线程的两种主要方式:继承Thread类和实现Runnable接口
【10月更文挑战第20天】《JAVA多线程深度解析:线程的创建之路》介绍了Java中多线程编程的基本概念和创建线程的两种主要方式:继承Thread类和实现Runnable接口。文章详细讲解了每种方式的实现方法、优缺点及适用场景,帮助读者更好地理解和掌握多线程编程技术,为复杂任务的高效处理奠定基础。
171 2
|
11月前
|
数据采集 Java Python
爬取小说资源的Python实践:从单线程到多线程的效率飞跃
本文介绍了一种使用Python从笔趣阁网站爬取小说内容的方法,并通过引入多线程技术大幅提高了下载效率。文章首先概述了环境准备,包括所需安装的库,然后详细描述了爬虫程序的设计与实现过程,包括发送HTTP请求、解析HTML文档、提取章节链接及多线程下载等步骤。最后,强调了性能优化的重要性,并提醒读者遵守相关法律法规。
292 0