背景

        首先在多线程环境中,多线程计数操作,共享状态或者统计相关时间次数等,这些需要在多线程之间共享变量和修改变量,如此就需要在多线程间对该变量进行互斥操作和访问。

        但是如果我们要维护一个全局的线程安全的 int 类型变量 count, 下面这两行代码都是很危险的:

count ++;

count += n;

        我们知道, 高级语言中的一条语句, 并不是一个原子操作. 比如一个最简单的自增操作就分为三步:

  1. 从缓存取到寄存器
  2.  在寄存器加1
  3.  存入缓存。

        多个线程访问同一块内存时, 需要加锁来保证访问操作是互斥的。

所以, 我们可以在操作 count 的时候加一个互斥锁. 如下面的代码:

pthread_mutex_t count_lock = PTHREAD_MUTEX_INITIALIZER;

pthread_mutex_lock(&count_lock);

count++;

pthread_mutex_unlock(&count_lock);

        另一个办法就是, 让 count++ 和 count+=n 这样的语句变成原子操作. 一个原子操作必然是线程安全的. 有两种使用原子操作的方式:

1. 使用 gcc 的原子操作

2. 使用 c++11中STL中的 stomic 类的函数

在这里我只介绍 gcc 里的原子操作, 这些函数分成以下几组:

返回更新前的值

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, …)

返回更新后的值

type __sync_add_and_fetch (type *ptr, type value, …)

type __sync_sub_and_fetch (type *ptr, type value, …)

type __sync_or_and_fetch (type *ptr, type value, …)

type __sync_and_and_fetch (type *ptr, type value, …)

type __sync_xor_and_fetch (type *ptr, type value, …)

type __sync_nand_and_fetch (type *ptr, type value, …)

        以下两个函数提供原子的比较和交换

bool __sync_bool_compare_and_swap (type *ptr, type oldval type newval, …)

type __sync_val_compare_and_swap (type *ptr, type oldval type newval, …)

如果*ptr == oldval,就将newval写入*ptr,

第一个函数在相等并写入的情况下返回true.

第二个函数在返回操作之前的值。

将*ptr设为value并返回*ptr操作之前的值。

type __sync_lock_test_and_set (type *ptr, type value, …)

将*ptr置0

void __sync_lock_release (type *ptr, …)

        因为 gcc 具体实现的问题, 后面的可扩展参数 (…) 没有什么用, 可以省略掉.

        gcc 保证了这些接口都是原子的. 调用这些接口时, 前端串行总线会被锁住, 锁住了它, 其它 cpu 就不能从存储器获取数据. 从而保证对内存操作的互斥. 当然, 这种操作是有不小代价, 所以只能在操作小的内存才可以这么做. 上面的接口使用的 type 只能是 1, 2, 4 或 8 字节的整形, 即:

int8_t / uint8_t

int16_t / uint16_t

int32_t / uint32_t

int64_t / uint64_t

性能上:原子操作的速度是互斥锁的6~7倍。

有了这些函数, 就可以很方便的进行原子操作了, 以 count++ 为例,

count 初始值为0, 可以这么写

__sync_fetch_and_add(&count, 1);    //返回0, count现在等于1, 类似 count ++

count 初始值为0, 或者这么写

__sync_add_and_fetch(&count, 1);    //返回1, count现在等于1, 类似 ++ count

原子操作也可以用来实现互斥锁:

int a = 0;

#define LOCK(a) while (__sync_lock_test_and_set(&a,1)) {sched_yield();}

#define UNLOCK(a) __sync_lock_release(&a);

        sched_yield()这个函数可以使用另一个级别等于或高于当前线程的线程先运行。如果没有符合条件的线程,那么这个函数将会立刻返回然后继续执行当前线程的程序。

如果去掉 sched_yield(), 这个锁就会一直自旋.

示例

        有了这些函数,对于多线程对全局变量进行操作(自加、自减等)问题,我们就不用考虑线程锁,可以考虑使用上述函数代替,和使用pthread_mutex保护的作用是一样的,线程安全且性能上完爆线程锁。

        下面是对线程锁和原子操作使用对比,并且进行性能测试与对比。弄懂后并稍微改动一点点。代码中分别给出加锁、加线程锁、原子计数操作三种情况的比较。

代码

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <pthread.h>
#include <sched.h>
#include <linux/unistd.h>
#include <sys/syscall.h>
#include <linux/types.h>
#include <time.h>
#include <sys/time.h>
 
#define INC_TO 1000000 // one million
 
__u64 rdtsc ()
{
    __u32 lo, hi;
    __asm__ __volatile__
    (
       "rdtsc":"=a"(lo),"=d"(hi)
    );
 
    return (__u64)hi << 32 | lo;
}
 
int global_int = 0;
 
pthread_mutex_t count_lock = PTHREAD_MUTEX_INITIALIZER;//初始化互斥锁
 
pid_t gettid ()
{
    return syscall(__NR_gettid);
}
 
void * thread_routine1 (void *arg)
{
    int i;
    int proc_num = (int)(long)arg;
    
    __u64 begin, end;
    struct timeval tv_begin, tv_end;
    __u64 time_interval;
    
    cpu_set_t set;
    
    CPU_ZERO(&set);
    CPU_SET(proc_num, &set);
 
    if (sched_setaffinity(gettid(), sizeof(cpu_set_t), &set))
    {
		fprintf(stderr, "failed to set affinity\n");
        return NULL;
    }
    begin = rdtsc();
    gettimeofday(&tv_begin, NULL);
    for (i = 0; i < INC_TO; i++)
    {
        __sync_fetch_and_add(&global_int, 1);
    }
    gettimeofday(&tv_end, NULL);
    end = rdtsc();
    time_interval = (tv_end.tv_sec - tv_begin.tv_sec) * 1000000 + (tv_end.tv_usec - tv_begin.tv_usec);
    fprintf(stderr, "proc_num : %d, __sync_fetch_and_add cost %llu CPU cycle, cost %llu us\n", proc_num, end - begin, time_interval);
    
    return NULL;
}
 
void *thread_routine2(void *arg)
{
    int i;
    int proc_num = (int)(long)arg;
 
    __u64 begin, end;
    struct timeval tv_begin, tv_end;
    __u64 time_interval;
    
    cpu_set_t set;
    
    CPU_ZERO(&set);
    CPU_SET(proc_num, &set);
 
    if (sched_setaffinity(gettid(), sizeof(cpu_set_t), &set))
    {
        fprintf(stderr, "failed to set affinity\n");
        return NULL;
    }
    begin = rdtsc();
    gettimeofday(&tv_begin, NULL);
    for (i = 0; i < INC_TO; i++)
    {
        pthread_mutex_lock(&count_lock);
        global_int++;
        pthread_mutex_unlock(&count_lock);
    }
    gettimeofday(&tv_end, NULL);
    end = rdtsc();
    time_interval = (tv_end.tv_sec - tv_begin.tv_sec) * 1000000 + (tv_end.tv_usec - tv_begin.tv_usec);
    fprintf(stderr, "proc_num : %d, pthread_mutex_lock cost %llu CPU cycle, cost %llu us\n", proc_num, end - begin, time_interval);
    
    return NULL;  
}
 
void *thread_routine3(void *arg)
{
    int i;
    int proc_num = (int)(long)arg;
 
    __u64 begin, end;
    struct timeval tv_begin, tv_end;
    __u64 time_interval;
    
    cpu_set_t set;
    
    CPU_ZERO(&set);
    CPU_SET(proc_num, &set);
 
    if (sched_setaffinity(gettid(), sizeof(cpu_set_t), &set))
    {
        fprintf(stderr, "failed to set affinity\n");
        return NULL;
    }
    begin = rdtsc();
    gettimeofday(&tv_begin, NULL);
    for (i = 0; i < INC_TO; i++)
    {
        global_int++;
    }
    gettimeofday(&tv_end, NULL);
    end = rdtsc();
    time_interval = (tv_end.tv_sec - tv_begin.tv_sec) * 1000000 + (tv_end.tv_usec - tv_begin.tv_usec);
    fprintf(stderr, "proc_num : %d, no lock cost %llu CPU cycle, cost %llu us\n", proc_num, end - begin, time_interval);
    
    return NULL;
}
 
int main()
{
    int procs = 0;
	int all_cores = 0;
    int i;
    pthread_t *thrs;
 
    procs = (int)sysconf(_SC_NPROCESSORS_ONLN);
    if (procs < 0)
    {
	    fprintf(stderr, "failed to fetch available CPUs(Cores)\n");
        return -1;
    }
	all_cores = (int)sysconf(_SC_NPROCESSORS_CONF);
	if (all_cores < 0)
	{
		fprintf(stderr, "failed to fetch system configure CPUs(Cores)\n");
		return -1;
	}
	
	printf("system configure CPUs(Cores): %d\n", all_cores);
	printf("system available CPUs(Cores): %d\n", procs);
 
    thrs = (pthread_t *)malloc(sizeof(pthread_t) * procs);
    if (thrs == NULL)
    {
        fprintf(stderr, "failed to malloc pthread array\n");
        return -1;
    }
	
    printf("starting %d threads...\n", procs);
    
    for (i = 0; i < procs; i++)
    {
        if (pthread_create(&thrs[i], NULL, thread_routine1, (void *)(long) i))
        {
			fprintf(stderr, "failed to pthread create\n");
            procs = i;
            break;
        }
    }
 
    for (i = 0; i < procs; i++)
    {
        pthread_join(thrs[i], NULL);
    }
  
    printf("after doing all the math, global_int value is: %d\n", global_int);
    printf("expected value is: %d\n", INC_TO * procs);
 
	free (thrs);
    
    return 0;
}

运行结果

     每次修改不同thread_routine?()函数,重新编译即可测试不同情况。

g++ main.cpp -D _GNU_SOURCE -l pthread
 ./a.out

         不加锁下运行结果:

system configure CPUs(Cores): 8
system available CPUs(Cores): 8
starting 8 threads...
proc_num : 5, no lock cost 158839371 CPU cycle, cost 66253 us
proc_num : 6, no lock cost 163866879 CPU cycle, cost 68351 us
proc_num : 2, no lock cost 173866203 CPU cycle, cost 72521 us
proc_num : 7, no lock cost 181006344 CPU cycle, cost 75500 us
proc_num : 1, no lock cost 186387174 CPU cycle, cost 77728 us
proc_num : 0, no lock cost 186698304 CPU cycle, cost 77874 us
proc_num : 3, no lock cost 196089462 CPU cycle, cost 81790 us
proc_num : 4, no lock cost 200366793 CPU cycle, cost 83576 us
after doing all the math, global_int value is: 1743884
expected value is: 8000000

 线程锁下运行结果:

system configure CPUs(Cores): 8
system available CPUs(Cores): 8
starting 8 threads...
proc_num : 1, pthread_mutex_lock cost 9752929875 CPU cycle, cost 4068121 us
proc_num : 5, pthread_mutex_lock cost 10038570354 CPU cycle, cost 4187272 us
proc_num : 7, pthread_mutex_lock cost 10041209091 CPU cycle, cost 4188374 us
proc_num : 0, pthread_mutex_lock cost 10044102546 CPU cycle, cost 4189546 us
proc_num : 6, pthread_mutex_lock cost 10113533973 CPU cycle, cost 4218541 us
proc_num : 4, pthread_mutex_lock cost 10117540197 CPU cycle, cost 4220212 us
proc_num : 3, pthread_mutex_lock cost 10160384391 CPU cycle, cost 4238083 us
proc_num : 2, pthread_mutex_lock cost 10164464784 CPU cycle, cost 4239778 us
after doing all the math, global_int value is: 8000000
expected value is: 8000000

 原子操作__sync_fetch_and_add下运行结果:

system configure CPUs(Cores): 8
system available CPUs(Cores): 8
starting 8 threads...
proc_num : 3, __sync_fetch_and_add cost 2364148575 CPU cycle, cost 986129 us
proc_num : 1, __sync_fetch_and_add cost 2374990974 CPU cycle, cost 990652 us
proc_num : 2, __sync_fetch_and_add cost 2457930267 CPU cycle, cost 1025247 us
proc_num : 5, __sync_fetch_and_add cost 2463027030 CPU cycle, cost 1027373 us
proc_num : 7, __sync_fetch_and_add cost 2532240981 CPU cycle, cost 1056244 us
proc_num : 4, __sync_fetch_and_add cost 2555055054 CPU cycle, cost 1065760 us
proc_num : 0, __sync_fetch_and_add cost 2561248971 CPU cycle, cost 1068331 us
proc_num : 6, __sync_fetch_and_add cost 2558781396 CPU cycle, cost 1067314 us
after doing all the math, global_int value is: 8000000
expected value is: 8000000

通过测试结果可以看出:
 
        1. 不加锁的情况下,不能获得正确结果。
                测试结果表明,正确结果为8000000,而实际为1743884。表明多线程下修改全局计数,不加锁的话是错误的;

        2. 加锁情况下,无论是线程锁还是原子性操作,均可获得正确结果。

        3. 性能上__sync_fetch_and_add()完爆线程锁。


        从性能测试结果上看,__sync_fetch_and_add()速度大致是线程锁的4-5倍。

测试结果对比
类型平均CPU周期(circle)平均耗时(us)
不加锁18089006675449.13
线程锁100540919014193740.875
原子操作24834279061035881.25

注:如上的性能测试结果,表明__sync_fetch_and_add()速度大致是线程锁的4-5倍。

         24cores实体机测试结果,表明__sync_fetch_and_add()速度大致只有线程锁的2-3倍。

24 cores实体机测试结果
类型平均CPU周期(circle)平均耗时(us)
不加锁535457026233310.5
线程锁93319154804066156.667
原子操作37699007951643463.625

总结

总体看来,原子操作__sync_fetch_and_add()大大的优于线程锁。

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐