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

本文探讨了线程局部存储(TLS)的概念及其在Unix系统下的应用。解释了TLS如何帮助解决多线程环境下数据共享所带来的问题,并提供了两种实现TLS的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

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上也许可以忽略,但是在手机上就不知道会是什么情况了。

【基于QT的调色板】是一个使用Qt框架开发的色彩选择工具,类似于Windows操作系统中常见的颜色选取器。Qt是一个跨平台的应用程序开发框架,广泛应用于桌面、移动和嵌入式设备,支持C++和QML语言。这个调色板功能提供了横竖两种渐变模式,用户可以方便地选取所需的颜色值。 在Qt中,调色板(QPalette)是一个关键的类,用于管理应用程序的视觉样式。QPalette包含了一系列的颜色角色,如背景色、前景色、文本色、高亮色等,这些颜色可以根据用户的系统设置或应用程序的需求进行定制。通过自定义QPalette,开发者可以创建具有独特视觉风格的应用程序。 该调色板功能可能使用了QColorDialog,这是一个标准的Qt对话框,允许用户选择颜色。QColorDialog提供了一种简单的方式来获取用户的颜色选择,通常包括一个调色板界面,用户可以通过滑动或点击来选择RGB、HSV或其他色彩模型中的颜色。 横渐变取色可能通过QGradient实现,QGradient允许开发者创建线性或径向的色彩渐变。线性渐变(QLinearGradient)沿直线从一个点到另一个点过渡颜色,而径向渐变(QRadialGradient)则以圆心为中心向外扩散颜色。在调色板中,用户可能可以通过滑动条或鼠标拖动来改变渐变的位置,从而选取不同位置的颜色。 竖渐变取色则可能是通过调整QGradient的方向来实现的,将原本水平的渐变方向改为垂直。这种设计可以提供另一种方式来探索颜色空间,使得选取颜色更为直观和便捷。 在【colorpanelhsb】这个文件名中,我们可以推测这是与HSB(色相、饱和度、亮度)色彩模型相关的代码或资源。HSB模型是另一种常见且直观的颜色表示方式,与RGB或CMYK模型不同,它以人的感知为基础,更容易理解。在这个调色板中,用户可能可以通过调整H、S、B三个参数来选取所需的颜色。 基于QT的调色板是一个利用Qt框架和其提供的色彩管理工具,如QPalette、QColorDialog、QGradient等,构建的交互式颜色选择组件。它不仅提供了横竖渐变的色彩选取方式,还可能支持HSB色彩模型,使得用户在开发图形用户界面时能更加灵活和精准地控制色彩。
标题基于Spring Boot的手物品交易网站系统研究AI更换标题第1章引言阐述基于Spring Boot开发手物品交易网站的研究背景、意义、现状及本文方法与创新点。1.1研究背景与意义介绍手物品交易的市场需求和Spring Boot技术的适用性。1.2国内外研究现状概述当前手物品交易网站的发展现状和趋势。1.3论文方法与创新点说明本文采用的研究方法和在系统设计中的创新之处。第2章相关理论与技术介绍开发手物品交易网站所涉及的相关理论和关键技术。2.1Spring Boot框架解释Spring Boot的核心概念和主要特性。2.2数据库技术讨论适用的数据库技术及其在系统中的角色。2.3前端技术阐述与后端配合的前端技术及其在系统中的应用。第3章系统需求分析详细分析手物品交易网站系统的功能需求和性能需求。3.1功能需求列举系统应实现的主要功能模块。3.2性能需求明确系统应满足的性能指标和安全性要求。第4章系统设计与实现具体描述基于Spring Boot的手物品交易网站系统的设计和实现过程。4.1系统架构设计给出系统的整体架构设计和各模块间的交互方式。4.2数据库设计详细阐述数据库的结构设计和数据操作流程。4.3界面设计与实现介绍系统的界面设计和用户交互的实现细节。第5章系统测试与优化说明对系统进行测试的方法和性能优化的措施。5.1测试方法与步骤测试环境的搭建、测试数据的准备及测试流程。5.2测试结果分析对测试结果进行详细分析,验证系统是否满足需求。5.3性能优化措施提出针对系统性能瓶颈的优化建议和实施方案。第6章结论与展望总结研究成果,并展望未来可能的研究方向和改进空间。6.1研究结论概括本文基于Spring Boot开发手物品交易网站的主要发现和成果。6.2展望与改进讨论未来可能的系统改进方向和新的功能拓展。
1. 用户与权限管理模块 角色管理: 学生:查看个人住宿信息、提交报修申请、查看卫生检查结果、请假外出登记 宿管人员:分配宿舍床位、处理报修申请、记录卫生检查结果、登记晚归情况 管理员:维护楼栋与房间信息、管理用户账号、统计住宿数据、发布宿舍通知 用户操作: 登录认证:对接学校统一身份认证(模拟实现,用学号 / 工号作为账号),支持密码重置 信息管理:学生完善个人信息(院系、专业、联系电话),管理员维护所有用户信息 权限控制:不同角色仅可见对应功能(如学生无法修改床位分配信息) 2. 宿舍信息管理模块 楼栋与房间管理: 楼栋信息:名称(如 "1 号宿舍楼")、层数、性别限制(男 / 女 / 混合)、管理员(宿管) 房间信息:房间号(如 "101")、户型(4 人间 / 6 人间)、床位数量、已住人数、可用状态 设施信息:记录房间内设施(如空调、热水器、桌椅)的配置与完好状态 床位管理: 床位编号:为每个床位设置唯一编号(如 "101-1" 表示 101 房间 1 号床) 状态标记:标记床位为 "空闲 / 已分配 / 维修中",支持批量查询空闲床位 历史记录:保存床位的分配变更记录(如从学生 A 调换到学生 B 的时间与原因) 3. 住宿分配与调整模块 住宿分配: 新生分配:管理员导入新生名单后,宿管可按专业集中、性别匹配等规则批量分配床位 手动分配:针对转专业、复学学生,宿管手动指定空闲床位并记录分配时间 分配结果公示:学生登录后可查看自己的宿舍信息(楼栋、房间号、床位号、室友列表) 调整管理: 调宿申请:学生提交调宿原因(如室友矛盾、身体原因),选择意向宿舍(需有空位) 审批流程:宿管审核申请,通过后执行床位调换,更新双方住宿信息 换宿记录:保存调宿历史(申请人、原床位、新床位、审批人、时间) 4. 报修与安全管理模块 报修管理: 报修提交:学生选择宿舍、设施类型(如 "
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值