系统程序员成长计划-内存管理(二)

 

Thursday, April 23rd, 2009 | Author: admin

转载时请注明出处和作者联系方式
文章出处:http://www.limodev.cn/blog
作者联系方式:李先静 <xianjimli at hotmail dot com>

线程局部存储(TLS)

同一个进程中的多个线程,它们的内存空间是共享的(栈除外),一个线程对内存的修改,对所有线程都有效。这是一个优点也是一个缺点。说它是优点,线程间的数据交换快捷高效。说它是缺点,一个线程死掉了,其它线程也性命不保。

在unix下,大家一直都对线程不太感兴趣,直到很晚以后才引入真正的线程。像X Sever要同时处理N个客户端的连接,每秒钟要响应上百万个请求,开发人员宁愿自己实现调度机制也不用线程。再如Apache(1.3x),在unix下的实现也是采用多进程的。

正如《unix编程艺术》中所说,线程局部存储的出现,使得这种情况出现了转机。采用线程局部存储,每个线程有一定的私有空间。这可以避免部分无意的破坏(当然无法避免有意的破坏行为),也省去线程访问共享数据时出现的问题。

其实这完全是因为unix程序不喜欢面向对象方法引起的,数据没有很好的封装起来,全局变量满天飞,在多线程情况下自然容易出问题。如果采用面向对象的方法,情况将会大为改观,而无需要线程局部存储来帮忙。

不过,多一种技术就多一种选择,知道线程局部存储肯定没有坏处。在有的情况下,没有线程局部存储,确实很难用其它办法实现。 比如,glibc会把最后一次操作的错误码记录在errno变量里,如果不采用线程局部存储,在多线程的情况下,当前线程取的errno可能不是自己上一次操作的错误码。

线程局部存储在不同的平台有不同的实现,可移植性不太好。幸好要实现线程局部存储并不难,最简单的办法就是建立一个全局表,通过当前线程ID去查询相应的数据,因为各个线程的ID不同,查到的数据自然也不同了。

大多数平台都提供了线程局部存储的方法,无需要我们自己去实现,在Linux下有两种方法可以实现线程局部存储。

方法一: 使用pthread的函数

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);

示例:

static pthread_key_t key;
static pthread_once_t key_once = PTHREAD_ONCE_INIT; 

static void make_key(void)
{
    pthread_key_create(&key, NULL); 

    return;
} 

void* thread_entry(void* param)
{
    pthread_once(&key_once, make_key); 

    if (pthread_getspecific(key) == NULL)
    {
        pthread_setspecific(key, (void*)pthread_self());
    } 

    printf("data=%u/n", pthread_getspecific(key)); 

    return NULL;
}

pthread_once保证make_key只被执行一次。

方法二: 使用编译器扩展

示例:

__thread int i;

后者使用起来方便很多,但前者的好处是移植比较方便,即使编译器不支持,也可以自己封装相应的函数。

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

5 Responses

  1. 请教下:这个make_key 是在各线程里面做,还是创建线程做啊?
    如果是在线程里面自己做,何必要用pthread_once呢?在线程函数开始的地方做不就好了?

  2. 汗一个,所谓的面向对象的所谓的封装,都只是语法层面的,所谓的private成员,用过指针偏移难道就不能访问了?但是你能用指针偏移来访其他进程的数据吗?进程间的内存保护是更加彻底的封装。
    另外文中的意思似乎是UNIX下的程序大多喜欢全局变量满天飞,而且UNIX下的程序是TLS的主要需求方?如果是这样,能举个例子吗?
    在线程机制里添加TLS明显就是打补丁的行为。UNIX传统是能隔离的内存都隔离出来(多进程的程序设计),只有在必要的时候才使用共享内存;而线程则是能共享的都共享了先,只有在必要的时候才使用TLS。线程的问题恰恰就是内存封装不足,不管是面向对象还是面向火星,都解决不了这个问题。如果真的重视封装,那么应该会更偏向于进程而不是线程,就好象应该先把自家房子院子都用围墙围起来,然后再选择性地开门,而不是线程那样先全部暴露出去,然后再这挡一下、那挡一下。

  3. 这段代码是从MAN里拷贝过来的,它存在问题的可能性不大。
    为什么要这样写呢?我想90%的人都会有这样的疑问。在创建线程的时候就创建好这个key,确实可以不要pthread_once。
    但是那意料着,线程的创建者要知道线程的实现细节,比如这里用了TLS,这不符合信息隐藏的原则。线程自己需要什么,由它自己去做。

  4. 汗一个,所谓的面向对象的所谓的封装,都只是语法层面的,所谓的private成员,用过指针偏移难道就不能访问了?但是你能用指针偏移来访其他进程的数据吗?进程间的内存保护是更加彻底的封装。
    >对于自杀式的程序,多进程的保护也无效。

    另外文中的意思似乎是UNIX下的程序大多喜欢全局变量满天飞,而且UNIX下的程序是TLS的主要需求方?如果是这样,能举个例子吗?
    >TLS的需求源于:全局变量+多线程。几年前,我们项目中要用到tidy_html,这是w3c提供的一个小工具,它把HTML文件转换成XHTML文件,它设计和实现都不错,但是用了全局变量来保存中间结果。当我们想把它修改成多线程的,让它同时tidy多个文件时就遇到了问题。有两种解决方案:一种方法是把全局变量改为TLS的。另外一种方法是按面向对象方法进行封装,每个线程自己的中间数据放在自己的对象中。我们选择了后者。

    在线程机制里添加TLS明显就是打补丁的行为。UNIX传统是能隔离的内存都隔离出来(多进程的程序设计),只有在必要的时候才使用共享内存;而线程则是能共享的都共享了先,只有在必要的时候才使用TLS。线程的问题恰恰就是内存封装不足,不管是面向对象还是面向火星,都解决不了这个问题。如果真的重视封装,那么应该会更偏向于进程而不是线程,就好象应该先把自家房子院子都用围墙围起来,然后再选择性地开门,而不是线程那样先全部暴露出去,然后再这挡一下、那挡一下。
    >TLS是打补丁的行为。我也这样认为,除非不得已,我不会用它。用面向对象来代替全局变量,可以不用TLS,让多线程并发成为可能。另外说明一下,这里多线程并发是指多个线程并发的做同样的事情,和多个线程之间的协作不同,多线程协作是用不上TLS的,因为数据共享是期望的行为。

    >前面的表达是有些问题,谢谢你的问题,我再考虑一下怎么去改。

  5. 呃,自杀式进程是指什么样的进程呢?我想除了病毒,正常的程序不管怎么出bug都应该不会影响到其他进程的内存吧。
    当时是什么原因要把那个工具改为多线程的呢?如果用多进程的方式能不能解决问题?
    全局变量的问题,在我印象中好像不管是否涉及面向对象,全局变量都是不被提倡的,我想这个应该是比面向对象这些“面向”系列更为底层或者根本的问题。可能一方面是封装问题,有时把全局变量限制在文件范围内就不一样了,只不过这样的话数据仍然只有一份,所以另一方面的问题就是一开始设计的时候这些数据是单实例的还是有可能多实例的。后者可能与多线程方面的问题关系更紧密。
    收到TAOUP的影响,我现在对多线程的态度越来越保守了,更加倾向于多进程。不知道博主有没有空写篇文章讨论一下多进程与多线程在手机这种设备上的对比?我想进程与线程的开销差别在PC上也许可以忽略,但是在手机上就不知道会是什么情况了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值