linux线程库

① linux系统中线程同步实现机制有哪些

LinuxThread的线程机制

LinuxThreads是目前Linux平台上使用最为广泛的线程库，由Xavier Leroy ([email protected]) 负责开发完成，并已绑定在GLIBC中发行。它所实现的就是基于核心轻量级进程的"一对一"线程模型，一个线程实体对应一个核心轻量级进程，而线程之间的 管理在核外函数库中实现。

1.线程描述数据结构及实现限制

LinuxThreads定义了一个struct _pthread_descr_struct数据结构来描述线程，并使用全局数组变量 __pthread_handles来描述和引用进程所辖线程。在__pthread_handles中的前两项，LinuxThreads定义了两个全 局的系统线程：__pthread_initial_thread和__pthread_manager_thread，并用 __pthread_main_thread表征__pthread_manager_thread的父线程（初始为 __pthread_initial_thread）。

struct _pthread_descr_struct是一个双环链表结构，__pthread_manager_thread所在的链表仅包括它 一个元素，实际上，__pthread_manager_thread是一个特殊线程，LinuxThreads仅使用了其中的errno、p_pid、 p_priority等三个域。而__pthread_main_thread所在的链则将进程中所有用户线程串在了一起。经过一系列 pthread_create()之后形成的__pthread_handles数组将如下图所示：

图2 __pthread_handles数组结构

新创建的线程将首先在__pthread_handles数组中占据一项，然后通过数据结构中的链指针连入以__pthread_main_thread为首指针的链表中。这个链表的使用在介绍线程的创建和释放的时候将提到。

LinuxThreads遵循POSIX1003.1c标准，其中对线程库的实现进行了一些范围限制，比如进程最大线程数，线程私有数据区大小等等。在 LinuxThreads的实现中，基本遵循这些限制，但也进行了一定的改动，改动的趋势是放松或者说扩大这些限制，使编程更加方便。这些限定宏主要集中 在sysdeps/unix/sysv/linux/bits/local_lim.h（不同平台使用的文件位置不同）中，包括如下几个：

每进程的私有数据key数，POSIX定义_POSIX_THREAD_KEYS_MAX为128，LinuxThreads使用 PTHREAD_KEYS_MAX，1024；私有数据释放时允许执行的操作数，LinuxThreads与POSIX一致，定义 PTHREAD_DESTRUCTOR_ITERATIONS为4；每进程的线程数，POSIX定义为64，LinuxThreads增大到1024 （PTHREAD_THREADS_MAX）；线程运行栈最小空间大小，POSIX未指定，LinuxThreads使用 PTHREAD_STACK_MIN，16384（字节）。

2.管理线程

"一对一"模型的好处之一是线程的调度由核心完成了，而其他诸如线程取消、线程间的同步等工作，都是在核外线程库中完成的。在LinuxThreads 中，专门为每一个进程构造了一个管理线程，负责处理线程相关的管理工作。当进程第一次调用pthread_create()创建一个线程的时候就会创建 （__clone()）并启动管理线程。

在一个进程空间内，管理线程与其他线程之间通过一对"管理管道（manager_pipe[2]）"来通讯，该管道在创建管理线程之前创建，在成功启动 了管理线程之后，管理管道的读端和写端分别赋给两个全局变量__pthread_manager_reader和 __pthread_manager_request，之后，每个用户线程都通过__pthread_manager_request向管理线程发请求， 但管理线程本身并没有直接使用__pthread_manager_reader，管道的读端（manager_pipe[0]）是作为__clone ()的参数之一传给管理线程的，管理线程的工作主要就是监听管道读端，并对从中取出的请求作出反应。

创建管理线程的流程如下所示：
（全局变量pthread_manager_request初值为-1）

图3 创建管理线程的流程

初始化结束后，在__pthread_manager_thread中记录了轻量级进程号以及核外分配和管理的线程id， 2*PTHREAD_THREADS_MAX+1这个数值不会与任何常规用户线程id冲突。管理线程作为pthread_create()的调用者线程的 子线程运行，而pthread_create()所创建的那个用户线程则是由管理线程来调用clone()创建，因此实际上是管理线程的子线程。（此处子 线程的概念应该当作子进程来理解。）

__pthread_manager()就是管理线程的主循环所在，在进行一系列初始化工作后，进入while(1)循环。在循环中，线程以2秒为 timeout查询（__poll()）管理管道的读端。在处理请求前，检查其父线程（也就是创建manager的主线程）是否已退出，如果已退出就退出 整个进程。如果有退出的子线程需要清理，则调用pthread_reap_children()清理。

然后才是读取管道中的请求，根据请求类型执行相应操作（switch-case）。具体的请求处理，源码中比较清楚，这里就不赘述了。

3.线程栈

在LinuxThreads中，管理线程的栈和用户线程的栈是分离的，管理线程在进程堆中通过malloc()分配一个THREAD_MANAGER_STACK_SIZE字节的区域作为自己的运行栈。

用户线程的栈分配办法随着体系结构的不同而不同，主要根据两个宏定义来区分，一个是NEED_SEPARATE_REGISTER_STACK，这个属 性仅在IA64平台上使用；另一个是FLOATING_STACK宏，在i386等少数平台上使用，此时用户线程栈由系统决定具体位置并提供保护。与此同 时，用户还可以通过线程属性结构来指定使用用户自定义的栈。因篇幅所限，这里只能分析i386平台所使用的两种栈组织方式：FLOATING_STACK 方式和用户自定义方式。

在FLOATING_STACK方式下，LinuxThreads利用mmap()从内核空间中分配8MB空间（i386系统缺省的最大栈空间大小，如 果有运行限制（rlimit），则按照运行限制设置），使用mprotect()设置其中第一页为非访问区。该8M空间的功能分配如下图：

图4 栈结构示意

低地址被保护的页面用来监测栈溢出。

对于用户指定的栈，在按照指针对界后，设置线程栈顶，并计算出栈底，不做保护，正确性由用户自己保证。

不论哪种组织方式，线程描述结构总是位于栈顶紧邻堆栈的位置。

4.线程id和进程id

每个LinuxThreads线程都同时具有线程id和进程id，其中进程id就是内核所维护的进程号，而线程id则由LinuxThreads分配和维护。

② LinuxC++如何编写线程安全库

LinuxC++编写线程安全库dll的方法：
1、动态库只有一个导出函数。
这种情况下编写函数时，只需要考虑不要有冲突的全局数据就可以了。这里的全局数据包括了在堆中分配的数据块和静态全局变量等。如果存在这样的全局数据，那么进程中的不同线程访问这个函数就会造成冲突。
2、动态库导出了多个函数，而且多个函数间存在数据传递。
一般DLL都导出多个函数，一个初始化，一个资源释放，其他为核心功能函数。这些函数间极有可能发生数据传递。如果一个初始化函数是在线程A中调用的，而核心功能函数是在线程B中调用的，那么线程A初始化函数的资源就无法对应线程B中的核心功能，此外还有核心功能函数间的数据传递，这样的DLL就不是线程安全的，必然导致错误。
解决办法是由用户（即使用DLL的人）保证这些导出函数是在一个线程中调用。但这样会很大程度上限制接口的设计和用户的使用自由度。所以最好的方法是函数只管自己的线程安全，不同函数传递数据用动态TLS，线程局部存储。
3、限制访问DLL中某一函数的线程数目。
对于DLL中的某一个函数的访问线程数目是有限制的，超过了限制其他线程就得等一定的时间，一定的时间过后如果还不能得到执行机会，那就返回超时。这样的设计对用户来说是友好的，而且很实用，有的商业程序确实是按照允许用户访问的通道数目来计价的。
对DLL中的函数做这样的一个封装，一般是简单的待用Semaphore信号量，来解决。DLL初始化时调用CreateSemaphore函数对信号量进行初始化，其原型如下：
HANDLE CreateSemaphore(
LPSECURITY_ATTRIBUTES lpSemaphoreAttributes,
// pointer to security attributes
LONG lInitialCount, // initial count
LONG lMaximumCount, // maximum count
LPCTSTR lpName // pointer to semaphore-object name
);
对于信号量，它每WaitForSingleObject一次（当然是要进入），其状态值（一个整数）就减1，使用完ReleaseSemaphore其状态值就加1，当其状态值为0时信号量就由有信号变为无信号。利用信号量的这一特性，我们在初始化时将信号量的初始值（第2个参数）设置为限制的线程访问数目。在要限制访问线程数目的函数内部，通过调用WaitForSingleOject获取控制权，并指定一个等待时间（这个由配置文件指定），根据情况超时返回，使用完ReleaseSemaphore释放对占用，让其他线程可以调用这个函数。
4、多进程情况下的多线程安全DLL。
LL是可以被多个进行加载并调用的。那就是说如果我们只对一个进程进行了限制，那么在多进程调用的情况下，这样的限制被轻易攻破。
我们都知道，Semaphore信号量属于内核对象，也就是说其可以被多进程共享访问，也就说，如果我们给一个Semaphore指定了一个名字，在另一个进程中，我们只要调用OpenSemaphore函数用同一名字打开信号量就可以访问了。这样问题就解决了？
现实情况是，多进程情况下，一般不是简单的多进程共享一个Semaphore就可以了。多进程间需要互通很多信息。一般的解决办法是，采用共享数据段。
#pragma data_seg("share")
int share_data;
#pragma data_seg()
#pragma comment(linker,"/SECTION:share, RWS")
通过pragam编译器指令生成了一个名叫share的共享数据段，这样对于变量share_data就可以多进程共享的了。如果要多进程间交换数据，只要在data_seg中添加数据定义即可。

③ Linux的线程库为什么是放在glibc中来实现

线程的实现有user level thread，kernel-level thread和两者结合的方式。Linux的实现了kernel-level thread，共享进程地址空间的进程相当于线程。
PThread是user level thread，内核根本不了解其线程的存在，不会对其中的线程进行调度，更不会对其进行代码实现。

④ Linux下的线程库pthread库中的pthread_create()函数创建两个线程。

void * thread1() //线程1
{
//............. pthread_mutex_lock(&mut);
a += 1; //①
b = a; //②
pthread_mutex_unlock(&mut);
}

void * thread2() //线程2
{
//.............
pthread_mutex_lock(&mut);
a += 2;
pthread_mutex_unlock(&mut);
}

这样就行呀， 加锁后另一个要等待锁释放

⑤ C++在linux下怎么多线程

#ifndefTHREAD_H_
#defineTHREAD_H_
#include<unistd.h>
#include<pthread.h>
classRunnable
{
public:
//运行实体
virtualvoidrun()=0;
};
//线程类
classThread:publicRunnable
{
private:
//线程初始化号
staticintthread_init_number;
//当前线程初始化序号
intcurrent_thread_init_number;
//线程体
Runnable*target;
//当前线程的线程ID
pthread_ttid;
//线程的状态
intthread_status;
//线程属性
pthread_attr_tattr;
//线程优先级
sched_paramparam;
//获取执行方法的指针
staticvoid*run0(void*pVoid);
//内部执行方法
void*run1();
//获取线程序号
staticintget_next_thread_num();
public:
//线程的状态－新建
staticconstintTHREAD_STATUS_NEW=0;
//线程的状态－正在运行
staticconstintTHREAD_STATUS_RUNNING=1;
//线程的状态－运行结束
staticconstintTHREAD_STATUS_EXIT=-1;
//构造函数
Thread();
//构造函数
Thread(Runnable*target);
//析构
~Thread();
//线程的运行体
voidrun();
//开始执行线程
boolstart();
//获取线程状态
intget_state();
//等待线程直至退出
voidjoin();
//等待线程退出或者超时
voidjoin(unsignedlongmillis_time);
//比较两个线程时候相同，通过current_thread_init_number判断
booloperator==(constThread*other_pthread);
//获取this线程ID
pthread_tget_thread_id();
//获取当前线程ID
staticpthread_tget_current_thread_id();
//当前线程是否和某个线程相等，通过tid判断
staticboolis_equals(Thread*iTarget);
//设置线程的类型:绑定/非绑定
voidset_thread_scope(boolisSystem);
//获取线程的类型:绑定/非绑定
boolget_thread_scope();
//设置线程的优先级，1－99，其中99为实时，意外的为普通
voidset_thread_priority(intpriority);
//获取线程的优先级
intget_thread_priority();
};
intThread::thread_init_number=1;
inlineintThread::get_next_thread_num()
{
returnthread_init_number++;
}
void*Thread::run0(void*pVoid)
{
Thread*p=(Thread*)pVoid;
p->run1();
returnp;
}
void*Thread::run1()
{
thread_status=THREAD_STATUS_RUNNING;
tid=pthread_self();
run();
thread_status=THREAD_STATUS_EXIT;
tid=0;
pthread_exit(NULL);
}
voidThread::run()
{
if(target!=NULL)
{
(*target).run();
}
}
Thread::Thread()
{
tid=0;
thread_status=THREAD_STATUS_NEW;
current_thread_init_number=get_next_thread_num();
pthread_attr_init(&attr);
}
Thread::Thread(Runnable*iTarget)
{
target=iTarget;
tid=0;
thread_status=THREAD_STATUS_NEW;
current_thread_init_number=get_next_thread_num();
pthread_attr_init(&attr);
}
Thread::~Thread()
{
pthread_attr_destroy(&attr);
}
boolThread::start()
{
returnpthread_create(&tid,&attr,run0,this);
}
inlinepthread_tThread::get_current_thread_id()
{
returnpthread_self();
}
inlinepthread_tThread::get_thread_id()
{
returntid;
}
inlineintThread::get_state()
{
returnthread_status;
}
voidThread::join()
{
if(tid>0)
{
pthread_join(tid,NULL);
}
}
voidThread::join(unsignedlongmillis_time)
{
if(tid==0)
{
return;
}
if(millis_time==0)
{
join();
}
else
{
unsignedlongk=0;
while(thread_status!=THREAD_STATUS_EXIT&&k<=millis_time)
{
usleep(100);
k++;
}
}
}
boolThread::operator==(constThread*other_pthread)
{
if(other_pthread==NULL)
{
returnfalse;
}if(current_thread_init_number==(*other_pthread).current_thread_init_number)
{
returntrue;
}
returnfalse;
}
boolThread::is_equals(Thread*iTarget)
{
if(iTarget==NULL)
{
returnfalse;
}
returnpthread_self()==iTarget->tid;
}
voidThread::set_thread_scope(boolisSystem)
{
if(isSystem)
{
pthread_attr_setscope(&attr,PTHREAD_SCOPE_SYSTEM);
}
else
{
pthread_attr_setscope(&attr,PTHREAD_SCOPE_PROCESS);
}
}
voidThread::set_thread_priority(intpriority)
{
pthread_attr_getschedparam(&attr,&param);
param.__sched_priority=priority;
pthread_attr_setschedparam(&attr,&param);
}
intThread::get_thread_priority(){
pthread_attr_getschedparam(&attr,&param);
returnparam.__sched_priority;
}
#endif/*THREAD_H_*/

⑥ linux系统多线程序为什么链接线程库

IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际编程之后，综合来...

⑦ linux 有什么线程库支持正真意义上的并发，可同时在多个cpu上运行多个线程

注意你说的是“多个CPU核心”还是“多个CPU”
如果你只一个CPU上的多个核心并发运行多个线程，那么linux上用pthread线程库最好了，gcc原生支持。
如果你指多个CPU，那么假设你指的是开放式内存架构，多计算机集群，那么用MPI讯息传递接口开发最好了。

⑧ 严重关注：在嵌入试LINUX系统该使用哪个线程库

严重关注： 在嵌入试LINUX系统该使用哪个线程库? 2006-12-13 21:30:02
分类： LINUX

在Redhat9.0下面， 创建一个进程。getpid();得到进程ID，然后在进程里用pthreadcreate几个线程，在线程里调用getpid, pthreadgetselfid()的到进程ID和线程ID， 发现该线程的进程ID和它所属的进程ID是一样的， 线程ID却不同。当是在小机里用gcc里的线程库，得到的结果是线程ID和进程ID是不同的，即线程也当作进程来对待，而且多了几个其它线程在运行，若线程当作进程来对待效率是比较低的。在网上查了下linux的线程库，发现新内核中的LD用的是The Native POSIX Thread Library （NPTL）， 而小机上用的是老的GCC里的线程库。
如何在Redhat9上面用老的线程库呢，在系统环境变量中加入LD_ASSUME_KERNEL=2.4.19就OK了
因为老版本内核中是不用NPTL库的， 这样LD连接程序的时候就不用NPTL, 在PC LINUX的
小机模拟器的模拟就和小机一样不用NPTL了。
那么到底是不是该把小机的线程库换成NPTL呢， 看看来自http://www-128.ibm.com/developerworks/cn/linux/l-nptl/?ca=dwcn-newsletter-linux的测试吧：

Linux 线程库性能测试与分析
杨沙洲国防科技大学计算机学院

2004 年 7 月 01 日
NPTL 成为 glibc "正选"线程库后，它的性能如何受到很多人的关注。本文就针对NPTL 与 LinuxThreads 的性能比较，以及超线程、内核可抢占等特性对线程性能的影响进行了全面评测。
一、 前言
在 Linux 2.6.x 内核中，调度性能的改进是其中最引人注目的一部分[1]。NPTL（Native Posix Thread Library）[2]使用内核的新特性重写了 Linux 的线程库，取代历史悠久而备受争议的 LinuxThreads[3] 成为 glibc 的首选线程库。
NPTL 的性能究竟如何？相对 LinuxThreads 又有哪些明显的改进？在对NPTL进行全面分析之前，本文针对这两种线程库，以及内核中"内核可抢占"（Preemptible）和超线程（HyperThreading）[4]等特性进行了全面的性能评测，结果表明NPTL绝对值得广大服务器系统期待和使用。

回页首

二、 Benchmark
1. 测试平台
进行本测试的硬件平台为浪潮NF420R服务器[7]，4个Hyperthreading-enabled Intel Xeon 2.2G处理器，4G内存。Linux选择了Slackware 9.0发行版[8]，所使用的内核源码来自 www.kernel.org。
2. 针对测试：LMBench
lmbench是一个用于评价系统综合性能的多平台开源benchmark[5]，但其中没有对线程的支持。其中有两个测试进程性能的benchmark：lat_proc用于评测进程创建和终止的性能，lat_ctx用于评测进程切换的开销。lmbench拥有良好的benchmark结构，只需要修改具体的Target程序（如lat_proc.c和lat_ctx.c），就可以借用lmbench的计时、统计系统得到我们关心的线程库性能的数据。
基于lat_proc和lat_ctx的算法，本文实现了lat_thread和lat_thread_ctx两个benchmark。在lat_thread中，lat_proc被改造成使用线程，用pthread_create()替代了fork()，用pthread_join()替代wait()；在lat_thread_ctx中，沿用lat_ctx的评测算法（见lat_ctx手册页），将创建进程的过程改写为创建线程，仍然使用管道进行通信和同步。
lat_thread null
null参数表示线程不进行任何实际操作，创建后即刻返回。
lat_thread_ctx -s #threads
size参数与lat_ctx定义相同，可表示线程的大小（实际编程时为分配K数据；#threads参数为线程数，即参与令牌传递的线程总数，相当于程序负载情况。
3. 综合测试：Volanomark
volanomark是一个纯java的benchmark，专门用于测试系统调度器和线程环境的综合性能[6]，它建立一个模拟Client/Server方式的Java聊天室，通过获取每秒平均发送的消息数来评测宿主机综合性能（数值越大性能越好）。Volanomark测试与Java虚拟机平台相关，本文使用Sun Java SDK 1.4.2作为测试用Java平台，Volanomark版本2.5.0.9。

回页首

三、 测试结果
测试计划中将内核分为2.4.26、2.6.6/支持内核抢占和2.6.6/不支持内核抢占三类；通过配置内核以及NF420R的BIOS实现三类SMP规模：单处理机(UP)、4CPU的SMP（SMP4）和打开超线程支持的虚拟8CPU SMP（SMP8*）。内核配置和SMP规模的每一种组合都针对LinuxThreads和NPTL使用lat_thread、lat_thread_ctx和volanomark获取一组数据。由于NPTL无法在2.4.x内核上使用，该项数据空缺。

回页首

四、 结果分析
1. LinuxThreads vs NPTL：线程创建/销毁开销
使用2.6.6/preemptible内核配置下UP和SMP4的测试数据获得下图：

图1

在线程创建/销毁开销方面，NPTL的改进相当明显（降低约600%）。实际上，NPTL不再像LinuxThreads那样需要使用用户级的管理线程来维护线程的创建和销毁[9]，因此，很容易理解它在这方面的开销能够大幅度降低。
同时，由图可见，单CPU下创建线程总是比多CPU下迅速。
2. LinuxThreads vs NPTL：线程切换开销
同样使用2.6.6/preemptible内核配置下UP和SMP4的数据：

图2

随着lat_thread_ctx的参与线程增多，不管是哪个线程库，单处理机条件下的线程切换开销都陡峭上升，而SMP条件下则上升比较平缓。在这方面，LinuxThreads和NPTL表现基本相同。
3. 内核影响

图3

图4

图5

图6

从上面四张图中我们可以得出两点结论：
"内核可抢占"是Linux对实时应用提供更好支持的有力保障，但对线程性能影响很小，甚至有一点损失，毕竟抢占锁的开销不可忽略；
升级内核并不会对LinuxThreads线程库性能带来多少变化，因此，对于服务器系统而言，不能指望仅仅编译使用新内核就能提高性能。

图7

图8

从图3、图4我们已经知道，打开超线程支持对线程创建/销毁性能几乎没有影响，而这两张图表也进一步说明，超线程技术对于线程切换开销也没有明显的影响。超线程技术是CPU内部的优化技术，和真正的双CPU完全不同。大量研究表明，如果没有内核与用户应用相结合的专门优化措施，超线程并不会带来很大的性能变化。除非是高负载综合服务器系统（例如繁忙的数据库系统），购买超线支持的CPU并不能带来多少好处。
4. 综合性能

图9

图9

前面几节分析让我们了解了线程库性能改进的细节，通过volanomark测试，我们可以近似得到在综合应用环境下，特别是网络服务需求中线程库以及内核对系统整体性能的影响程度。
图9综合了不同内核、不同处理机数条件下，两种线程库的volanomark结果。从图中可以观察到以下三点：
NPTL能极大提高SMP环境下服务器系统的整体性能（超过65%），相对而言，对单处理机系统影响较小（10%左右）；
2.6内核的抢占特性对系统性能影响很小（不超过±1%），某些情况下甚至有所下降；
超线程技术在LinuxThreads中的影响是负面的，在NPTL中是正面的，但影响幅度都很小（5%-6%）。
以上结论中前两点与LMBench针对性测试结果完全吻合，第三点的偏差实际上反映了超线程技术对于综合服务器环境还是有一定加速的。

⑨ 为什么linux的线程库是第三方库，像posix线程库里的线程和linux内核线程一样吗

严格来说，在Linux的体系中，用户空间是没有Thread这个概念的，Thread的相关实现是gcc等提供的模拟thread， gcc是使用了clone这个系统调用，利用linux的轻量级进程实现了类似thread的库。这些内容你可以在《unix环境高级编程》这本书里面看到很清晰完整的讲解。
至于Linux为何不在用户空间实现thread，这只是一种选择问题，读一下《操作系统-内核与设计原理》这本书应该有所帮助。

⑩ LINUX中GCC支持C++线程吗如果支持那么C++的线程库是什么

#include <thread> // GCC 4.7

#include <thread> // VC++11.0

#include <thread>
#include <iostream>

int main() {
std::thread t1([]() {

std::cout << "Hello," << std::endl;

});

std::thread t2([]() {

std::cout << "Fuck" << std::endl;
});

t1.join();

t2.join();

system("pause");

}