线程存储和共享内存

线程存储和共享内存 当我们发明了 MMU 时，大家认为天下太平了，各个进程空间独立，互不影响，程序的稳定性将大提 高。但马上又认识到，进程完全隔离也不行，因为各个进程之间需要信息共享。于是就搞出一种称为 共享内存的东西。 当我们发明了线程的时，大家认为这下可爽了，线程可以并发执行，创建和切换的开销相对进 程来说小多了。线程之间的内存是共享的，线程间通信快捷又方便。但马上又认识到，有些信息还是 不共享为好，应该让各个线程保留一点隐私。于是就搞出一个线程局部存储的玩意儿。 共享内存和线程局部存储是两个重要又不常用的东西，平时很少用，但有时候又离不了它们。本 文介绍将两者的概念、原理和使用 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 ，把它们放在自己的工具箱里，以供不时之需。 1 . 共享内存 大家都知道进程空间是独立的，它们之间互不影响。比如同是 0xabcd1234 地址的内存，在不 同的进程中，它们的数据是不同的，没有关系的。这样做的好处很多：每个进程的地址空间变大了， 它们独占 4G(32 位 )的地址空间，让编程实现更容易。各个进程空间独立，一个进程死掉了，不会影响 其它进程，提高了系统的稳定性。 要 做 到 进 程 空 间 独 立 ， 光 靠 软 件 是 难 以 实 现 的 ， 通 常 要 依 赖 于 硬 件 的 帮 助 。 这 种 硬 件 通 常 称 为 MMU(Memory Manage Unit)，即所谓的内存管理单元。在这种体系结构下，内存分为物理内存和虚拟 内存两种。物理内存就是实际的内存，你机器上装了多大内存就有多大内存。而应用程序中使用的是 虚拟内存，访问内存数据时，由 MMU 根据页表把虚拟内存地址转换对应的物理内存地址。 MMU 把 各个进程的虚拟内存映射到不同的物理内存上，这样就保证了进程的虚拟内存是独立 的。然而，物理内存往往远远少于各个进程的虚拟内存的总和。怎么办呢，通常 的办法是把暂时不用 的内存写到磁盘上去，要用的时候再加载回内存中来。一般会搞一个专门的分区保存内存数据，这就 是所谓的交换分区。 这些工作由内核配合 MMU 硬件完成，内存管理是内核的重要功能。其中为了优化性能，使用了 不少高级技术，所以内存管理通常比较复杂。比如：在决定把什么数据换出到磁盘上时，采用最近最 少使用的策略，把常 用的内存数据放在物理内存中，把不常用的写到磁盘上，这种策略的假设是最近 最少使用的内存在将来也很少使用。在创建进程时使用 COW(Copy on Write)的技术，大大减少了内 存数据的复制。为了提高从虚拟地址到物理地址的转换速度，硬件通常采用 TLB 技术，把刚转换的地 址存在 cache 里，下次可以直接使用。 操作系统从虚拟内存到物理内存的映射并不是一个字节一个字节映射的，而 是以一个称为页 (page)最 小单位的为基础的，页的大小视硬件平台而定，通常是 4K。当应用程序访问的内存所在页面不在物理 内存中时，MMU 产生一个缺页中断，并挂起当前进程，缺页中断负责把相应的数据从磁盘读入内存中， 再唤醒挂起的进程。 也许我们很少直接使用共享内存，实际上除非性能上有特殊要求，我更愿意采用 socket 或 者管道作 为进程间通信的方式。但我们常常间接的使用共享内存，大家都知道共享库（或称为动态库）的优点 是，多个应用程序可以公用。如果每个应用程序都加载 一份共享库到内存中，显然太浪费了。所以操 作系统把共享库放在共享内存中，让多个应用程序共享。另外，同一个应用程序运行多个实例时，也 采用同样的方式， 保证内存中只有一份可执行代码。这样的共享内存是设为只读属性的，防止应用程 序无意中破坏它们。当调试器要设置断点时，相应的页面被拷贝一分，设置为可写 的，再向其中写入 断点指令。这些事情完全由操作系统等底层软件处理了，应用程序本身无需关心。 共享内存是怎么实现的呢？实现共享内存非常容易，只是把两个进程的虚拟内存映射同一块物理内存 就行了。不过要注意，物理内存相同而虚拟地址却不一定相同。 如何在程序中使用共享内存呢？通常很简单，操作系统或者函数库提供了一些 API 给我们使用。如： Linux: void * mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset); int munmap(void *start, size_t length); Win32: HANDLE CreateFileMapping( HANDLE hFile, // handle to file LPSECURITY_ATTRIBUTES lpAttributes, // security DWORD flProtect, // protection DWORD dwMaximumSizeHigh, // high-order DWORD of size DWORD dwMaximumSizeLow, // low-order DWORD of size LPCTSTR lpName // object name ); BOOL UnmapViewOfFile( LPCVOID lpBaseAddress // starting address ); 2. 线程局部存储 (TLS) 同一个进程中的多个线程，它们的内存空间是共享的（栈除外），在一个线程修改的内存内容， 对所有线程都生效。这是一个优点也是一个缺点。 说它是优点，线程的数据交换变得非常快捷。说它 是缺点，一个线程死掉了，其它线程也性命不保 ; 多个线程访问共享数据，需要昂贵的同步开销，也容 易造成同步相关的 BUG;。 在 unix 下，大家一直都对线程不是很感兴趣，直到很晚以后才引入线程这东西。像 X Sever 要同时处 理 N 个客户端的连接，每秒钟要响应上百万个请求，开发人员宁愿自己实现调度机制也不用线程。让 人很难想象 X Server 是单进程单线程模型的。再如 Apache(1.3x)，在 unix 下的实现也是采用多进程 模型的，把像记分板等公共信息放入共享内存中，也不愿意采用多线程模型。 正如《 unix 编程艺术》中所说，线程局部存储的出现，使得这种情况出现了转机。采用线程局 部存储，每个线程有一定的私有空间。这可以避免部分无意的破坏，不过仍然无法避免有意的破坏行 为。 个人认为，这完全是因为 unix 程序不喜欢面向对象方法引起的，数据没有很好的封装起来，全 局变量满天飞，在多线程情况下自然容易出问题。如果采用面向对象的方法，可以让这种情况大为改 观，而无需要线程局部存储来帮忙。 当然，多一种技术就多一种选择，知道线程局部存储还是有用的。尽管只用过几次线程局部存 储的方法，在那种情况下，没有线程局部存储，确实很难用其它办法实现。 线程局部存储在不同的平台有不同的实现，可移植性不太好。幸好要实现线程局部存储并不难，最简 单的办法就是建立一个全局表，通过当前线程 ID 去查询相应的数据，因为各个线程的 ID 不同，查到 的数据自然也不同了。 大多数平台都提供了线程局部存储的方法，无需要我们自己去实现： l inux: int pthread_key_create(pthread_key_t *key, void (*destructor)(void*)); int pthread_key_delete(pthread_key_t key); void *pthread_getspecific(pthread_key_t key); int pthread_setspecific(pthread_key_t key, const void *value); Win32 方法一： DWORD TlsAlloc(VOID); BOOL TlsFree( DWORD dwTlsIndex // TLS index ); BOOL TlsSetValue( DWORD dwTlsIndex, // TLS index LPVOID lpTlsValue // value to store ); LPVOID TlsGetValue( DWORD dwTlsIndex // TLS index ); 方法二： __declspec( thread ) int tls_i = 1;