不应使用局部变量

可重入化，其中的静态数据应 该由它的调用者维护。
char reentrant_lowercase_c(char *string,int *p_index) { char c=0; for(;c=string[*p_index];(*p_index)++){ if(islower(c)){ (*p_index)++; break; } } return c; }
线程安全
• 一个线程安全的函数通过“锁”来保护 共享的资源不被并发地访问。“线程安 全”仅关心函数的实现，而不影响它的 外部接口。 • 局部变量是在栈上动态分配的，因此， 任何一个不使用静态数据和其它共享资 源的函数就是线程安全的。
线程安全化
• 在一个多线程的程序中，所有的被多线程调用 的函数多必须是线程安全的（或可重入的）。 注意，不可重入的函数一般都是线程“不安全” 的，然而，将它们改写成可重入的同时，一般 就会将它们变成线程安全的。 • 为共享资源加锁
可重入
• 可重入（reentrant）函数可以由多于 一个任务并发使用，而不必担心数据错 误。可重入函数可以在任意时刻被中断， 稍后再继续运行，不会丢失数据。 • 相反， 不可重入（non-reentrant）函 数不能由超过一个任务所共享，除非能 确保函数的互斥（或者使用信号量，或 者在代码的关键部分禁用中断）。
使用非安全函数库
1. 使用作用于整个函数的锁 2. 使用作用于单个库组件或是一组组件的 锁
使用作用于整个函数的锁
• 该解决方法可能造成性能瓶颈
使用作用于单个库组件或是一 组组件的锁
非可重入函数
可重入化
需要修改函数的对外接口
由调用者提供空间
• 一个可重入的函数不应该为后续的调用 保持数据（即后继的调用和本次调用无 关），因为下一次调用可能是由不同的 线程调用的。 • 如果一个函数需要在连续的调用之间维 护一些数据，例如一个工作缓冲区或是 一个指针，这些数据（资源）应该由调 用这个函数的函数提供。
可重入函数
• • • • 不使用静态数据。 不返回指向静态数据的指针； 使用到的数据都由函数的调用者提供。 使用本地数据，或者通过制作全局数据 的本地拷贝来保护全局数据。 • 如果必须访问全局变量，记住利用互斥 信号量来保护全局变量。 • 绝不调用任何不可重入函数。
不可重入函数
• 函数中使用了静态变量，无论是全局静态变量 还是局部静态变量。 • 函数返回静态变量。 • 函数中调用了不可重入函数。 • 函数体内使用了静态的数据结构； • 函数体内调用了malloc()或者free()函数； • 函数体内调用了其他标准I/O函数。 • 总的来说，如果一个函数在重入条件下使用了 未受保护的共享的资源，那么它是不可重入的。
1. 线程过多
• 当软件线程的个数超过CPU核数时，支 持抢占式多任务处理的操作系统一般会 采用时间片轮转调度的方案。 • 当系统从一个软件线程切换到另一个软 件线程时，它将保存被抢占的软件线程 的线程上下文，并重新加载线程队列中 下一个软件线程的上下文。
1. 线程过多
• 操作系统的时间片轮转调度方案也将引入额外 开销，随着软件线程的增多，这种开销将会急 剧增加，进而降低系统性能，这种开销有以下 几种：
1. 线程过多
• 最好的解决方案：
• 根据实际情况，使用尽可能少的线程，这样可以 最大限度地减少操作系统资源的使用，并可提高 性能。 • 不要硬性规定线程的个数，将其作为一个可调节 的参数。OpenMP可以根据需要近两使用最优 数量的线程个数。 • 使用线程池
2. 数据竞争、死锁和活锁
• 数据竞争
按地址给锁排序
• 要求线程知道将要访问的锁地址，才能 访问锁
活锁
• 活锁是不公平的资源分配策略引起的， 一般可以采用先来先服务的策略解决
线程安全函数和库
• 为了保证资源的完整性，多线程程序中 所使用的代码必须是可重入的和线程安 全的。 • 可重入的和线程安全是独立的概念，都 与函数处理资源有关
示例
• 可重入函数保证了在多线程条件下，函数的状态不会 出现错误。以下分别是一个不可重入和可重入函数的 示例： 编写可重入函 数时，应注意 • static int tmp; void func1(int* x, int* y) { 局部变量的使 tmp=*x; 用，不应使用 *x=*y; static局部变 *y=tmp; 量，否则必须 } 经过特殊处理， void func2(int* x, int* y) { 才能使函数具 int tmp; 有可重入性。 tmp=*x; *x=*y; *y=tmp; }
• 只要破坏以上条件就可以避免死锁
死锁和活锁
• 避免死锁
• 最好的方法是复制原本需要互斥访问的资源
• 如果资源无法复制，则按照一定的顺序获取 资源（锁），保持一致的锁获取顺序可避免 死锁环的出现。
ቤተ መጻሕፍቲ ባይዱ
每个线程按顺序申请资源锁
• 给每个资源锁分配一个唯一的整数，以 允许用户比较两个资源锁以确定其先后 顺序。
• 线程间切换时保存和恢复进程寄存器的开销。随着 线程数目的增加，系统分给每个线程的时间片相应 减少； • 使用时间片机制的时候，保存和恢复线程使用的 cache的开销则是更敏感的一种开销。 • 线程对主存的争夺，导致性能上的损失。
1. 线程过多
• 还存在一个性质不同，后果可能更加严 重的问题。
• 护航，指线程聚集在一起，等待获取某一个 锁。某个线程持有一个锁，并且用完了自己 的时间片，所有等待这个锁的线程必须等待 这个线程被唤醒并且释放锁。
• 使用静态数据或者其它任何共享资源（如文件、终 端等）的函数，必须对这些资源加“锁”以实现对 它们的串行访问，这样才能成为线程安全的函数
int increament_counter() { static int counter=0; counter++; return counter; } /* pseudo-code thread-safe function*/ int increment_counter() { static int counter=0; static lock_type counter_lock=LOCK_INITIALIZER; lock(counter_lock); counter++; unlock(counter_lock); return counter; }
多线程程序设计中的常见问题
内容
1. 线程过多 2. 数据竞争、死锁和活锁 3. 线程安全函数和库
1. 线程过多
• 线程是否是越多越好? • 多线程目的是为不同程序合理地安排运行时间, 充分利用系统资源 • 过多的线程可能会严重影响程序的性能。
• 将给定的工作量划分给过多的线程会造成每个线程 的工作量过少，因此可能导致线程启动和终止的开 销比程序实际工作的开销还要多； • 过多并发线程的存在将导致共享有限硬件资源的开 销增大。
• 对共享数据的非同步访问会引发数据竞争， 程序结果将以不确定的方式依赖两个或多个 线程的相对时间特性。
一个线程可能能够在其时间片执行全部代码，也有可 能只执行其中一部分代码，这就可能出现数据竞争
数据竞争
数据竞争
• 对共享数据的非同步访问会引起数据竞争 • 同步访问，如果同步层次比较低，也可能存在 数据竞争。 • arraylist容器用于包含一系列不重复的对象， 所以在将一个对象加入arraylist之前，要检 查该对象是否已经在arraylist里边，虽然保 证arraylist的每个操作不会出现数据竞争， 但是这些操作的组合可能引发高层次的数据竞 争。
例如：连续调用返回指定字符串 中的小写字符。
char lowercase_c(char *string) { static char *buffer; static int index; char c=0; if(string!=NULL){ buffer=string; index=0; } for(;c=buffer[index];index++){ if(islower(c)){ index++; break; } } return c; }
数据竞争
死锁和活锁
• 有大量的同步策略可以解决数据竞争问 题，其中最简单的就是锁。
• 锁在一定程度上能避免数据竞争，但是 也给软件开发带来了严重问题。 • 最主要的问题是，锁不具有可组合性。 • 造成组装失败的祸首是死锁。
死锁和活锁
• 死锁发生的四个条件：
• • • • 互斥（对共享资源的访问是互斥的） 占有并等待 非抢占（资源不能抢占） 循环等待