学习多线程编程面临的最大的思维方式的转变有两点:
- 当前线程可能随时会被切换出去,或者说被抢占了
- 多线程程序中事件的发生顺序不再有全局统一的先后关系
多线程程序的正确性不能依赖于任何一个线程的执行速度,不能通过原地等待来假定其他线程的事件已经发生,而必须通过适当的同步来让当前线程能够看到其他线程事件的结果。无论线程执行得快与慢(被操作系统切换出去得越多,执行越慢),程序都应该能够正常工作。
1. 基本线程原语的选用
本书只谈现代 linux 下的多线程编码。11最基本的 Pthreads 函数是:
- 2个:线程创建和等待结束(join)。
- 4个:mutex 的创建、销毁、加锁、解锁。
- 5个:条件变量的创建、销毁、等待、通知、广播。
多线程系统编程的难点不在于学习线程原语,而在于理解多线程与现有的C/C++库函数和系统调用的交互关系,以进一步学习如何设计并实现线程安全且高效的程序。
2. C/C++系统库的线程安全性
我们不必担心系统调用的线程安全性,因为系统调用对于用户态程序来说就是原子的。但是要注意系统调用对于内核状态的改变可能影响其他线程。
可以说现在的 glibc 库函数大部分都是线程安全的。特别是FILE* 系列函数是安全的,glibc 甚至提供了费线程安全版本以应对某些特殊场合的性能需求。
尽管单个函数是线程安全的,但两个或多个函数放到一块就不再安全了。线程安全程序的一个难点在于线程安全是可组合的,一个函数 foo() 调用了两个线程安全的函数,而这个 foo() 函数本身很可能不是线程安全的。即便大多数 glibc 库函数是线程安全的,我们也不能像写单线程程序那样编写代码。
例如,在单线程程序中,如果我们要临时转换时区,可以用txset() 函数,这个函数会改变程序全局的“当前时区”。
//获取伦敦的当前时间
string oldTz = getenv("TZ"); //save TZ,assumeing non-NULL
putenv("TZ=Europe/London"); //set TZ to London
tzset(); //load London time zone
struct tm localTimeInLN;
time_t now = time(NULL); //get time in UTC
localtime_r(&now, &localTimeInLN); //convert to London local time
setenv("TZ", oldTz.c_str(), 1); //restore old TZ
tzset(); //local old time zone
但是在多线程程序中,这么做是不安全的,即便tzset() 本身是线程安全的。因为他改变了全局状态,这有可能影响其他线程转换当前时间,或者被其他进行类似的操作的线程影响。解决办法是使用mudou::TimeZone class ,每个immutable instance 对应一个时期,这样时间转换就不需要修改全局状态了。例如:
class TimeZone
{
public:
explict TimeZone(const char* zonefile) ;
struct tm toLocalTime(time_t secondsSinceEpoch)const;
time_fromLocalTime(const struct tm&)const;
// default copy ctor /assigment /dtor are okay.
// ...
};
const TomeZone kNewYorkTz("/usr /share / zoneinfo / America /New_York”)
const TomeZone kLondonTz( " /usr / share / zoneinfo /Europe / London’’)
time_t now=time(NULL)
struct tm locaTimeInNY= kNewYorkTz.toLcalTime(now);
struct tm localTimeInLN = kLondonTz. toLocalTime (now);
对于c/c++库的作者来说,符合设计线程安全的接口也成了一大考验,值得效仿的例子并不多。一个基本的思路尽量吧class 设计成immutable 的,这样用起来就不必为线程安全操心了。
尽管c++03标准没有明说标准库的线程的安全性,但我们可以遵循一个基本的原则:凡是非共享的对象都是彼此独立的,如果一个对象从始至终只被一个线程用到,那么它就是安全的。
3. Linux 上的线程标识
POSIX threads 库提供了 pthread_self 函数用于返回当前进程的标识符,其类型为 pthread_t。pthread_t 不一定是一个数值类型,也有可能是一个结构体。这就带来了一些列问题,包括:
- 无法打印输出 pthread_t, 因为不知道其确切数据类型,也没有办法在日志中记录用它标识的当前线程的id。
- 无法比较 pthread_t 的大小或计算其 hash 值,因此无法用于关联容器的 key。
- 无法定义一个非法的 pthread_t 值,用来标识绝不可能存在的线程 id,因此MutexLock class 没有办法判断当前线程是否已经持有本锁。
- pthread_t 值只在进程内有意义,与操作系统的任务调度之间无法建立有效关联。比方说在/proc 文件系统中找不到 pthread_t 对应的 task。
另外,glibc 的 Pthreads 实际上把 pthread_t 用作一个结构体指针(它的类型是unsiged long),指向一块动态分配的内存,而且这块内存是反复使用的。这就造成 pthread_t 的值很容易重复。Pthreads 只保证同一进程内,同一时刻的各个线程的 id 不同;不能保证同一进程先后多个进程具有不同的 id,更不要说一台机器上多个进程之间的唯一性了。
例如下面这段代码中先后两个线程的标识符是相同的:
int main()
{
pthread_t t1, t2;
pthread_create(&t1, NULL, threadFunc, NULL);
printf("%lx\n", t1);
pthread_join(t1, NULL);
pthread_create(&t2, NULL, threadFunc, NULL);
printf("%lx\n", t2);
pthread_join(t2, NULL);
}
运行结果如下所示:
./a.out
7fad11787700
7fad11787700
因此,pthread_t 并不适合用作程序中对线程的标识符。
在linux上,建议使用 gettid(2) 系统调用的返回值作为线程id,这么做的好处有:
- 它的类型是pid_t,其值通常是一个小整数,便于在日志中输出。
- 在现代 linux 中,它直接表示内核的任务调度id,因此在 /proc 文件系统中可以轻易地找到对应项。
- 在其他系统工具中也容易定位到具体某一线程,例如在 top(1) 中我们可以按线程列出任务。
- 任何时刻都是全局唯一的,并且由 linux 分配新 pid 采用递增轮回办法,短时间内启动多个线程也不会具有不同的线程id。
- 0是非法值,因为操作系统第一个进程init 的 pid 是1。
4. 线程创建于销毁的守则
线程的创建于销毁是编写多线程程序的基本要素,线程的创建比销毁要容易的多,需要遵守的原则:
- 程序库不应该在未提前告知的情况下创建自己的“背景线程”。
- 尽量用相同的方式创建线程。
- 在进入 main() 函数之前不应启动线程
线程的销毁有几种方式:
- 自然死亡。从线程主函数返回,线程正常退出。
- 非正常死亡。从线程主函数抛出异常或线程触发 segfault 信号等非法操作。
- 自杀。在线程中调用 pthread_exit() 来立刻退出线程。
- 他杀。其他线程调用pthread_cancel()来强制终止某个线程。
5. 善用_ _thread 关键字
_ _thread 是GCC 内置的线程局部存储设施。它的实现非常高效,比pthread_key_t 快很多,其存取效率可与全局变量相比。
_ thread 使用规则:只能用于修饰POD类型,不能修饰class类型,因为无法自动调用构造函数和析构函数。 thread 可以用于修饰全局变量、函数内的静态变量,但是不能用于修饰函数的局部变量或者class的普通成员变量。另外, _thread 变量的初始化只能用编译期常量。
_ _thread 变量是每个线程有一份独立实体,各个线程的变量值互不干扰。除了这个主要用途,它还可以修饰那些 “值可能会变,带有全局性,但是又不值得用全局锁保护”的变量。
6. 多线程与IO
操作文件描述符的系统调用本身是线程安全的,我们不用担心多个线程同时操作会造成进程崩溃或内核崩溃。
但是,多个进程同时操作同一个socket 文件描述符确实很麻烦,我认为是得不偿失的。需要考虑的情况如下:
- 如果一个线程正在阻塞地 read(2) 某个 socket,而另一个线程 close(2) 了此socket。
- 如果一个线程正在阻塞地accept(2)某个listening socket,而另一个线程close(2)了此socket。
- 一个线程正准备 read(2) 某个 socket,而另一个线程close(2)了此socket;第三个线程又正好 open(2) 了另一个文件描述符,其fd号码正好与前面的socket 相同,这样程序逻辑就混乱了。
网友评论