posts - 200, comments - 8, trackbacks - 0, articles - 0

当 Linux 最初开发时,在内核中并不能真正支持线程。但是它的确可以通过 clone() 系统调用将进程作为可调度的实体。这个调用创建了调用进程(calling process)的一个拷贝,这个拷贝与调用进程共享相同的地址空间。LinuxThreads 项目使用这个调用来完全在用户空间模拟对线程的支持。不幸的是,这种方法有一些缺点,尤其是在信号处理、调度和进程间同步原语方面都存在问题。另外,这个 线程模型也不符合 POSIX 的要求。

要改进 LinuxThreads,非常明显我们需要内核的支持,并且需要重写线程库。有两个相互竞争的项目开始来满足这些要求。一个包括 IBM 的开发人员的团队开展了 NGPT(Next-Generation POSIX Threads)项目。同时,Red Hat 的一些开发人员开展了 NPTL 项目。NGPT 在 2003 年中期被放弃了,把这个领域完全留给了 NPTL。

尽管从 LinuxThreads 到 NPTL 看起来似乎是一个必然的过程,但是如果您正在为一个历史悠久的 Linux 发行版维护一些应用程序,并且计划很快就要进行升级,那么如何迁移到 NPTL 上就会变成整个移植过程中重要的一个部分。另外,我们可能会希望了解二者之间的区别,这样就可以对自己的应用程序进行设计,使其能够更好地利用这两种技 术。

本文详细介绍了这些线程模型分别是在哪些发行版上实现的。

LinuxThreads 设计细节

线程 将应用程序划分成一个或多个同时运行的任务。线程与传统的多任务进程 之间的区别在于:线程共享的是单个进程的状态信息,并会直接共享内存和其他资源。同一个进程中线程之间的上下文切换通常要比进程之间的上下文切换速度更 快。因此,多线程程序的优点就是它可以比多进程应用程序的执行速度更快。另外,使用线程我们可以实现并行处理。这些相对于基于进程的方法所具有的优点推动 了 LinuxThreads 的实现。

LinuxThreads 最初的设计相信相关进程之间的上下文切换速度很快,因此每个内核线程足以处理很多相关的用户级线程。这就导致了一对一 线程模型的革命。

让我们来回顾一下 LinuxThreads 设计细节的一些基本理念:

  • LinuxThreads 非常出名的一个特性就是管理线程(manager thread)。管理线程可以满足以下要求:

    • 系统必须能够响应终止信号并杀死整个进程。
    • 以堆栈形式使用的内存回收必须在线程完成之后进行。因此,线程无法自行完成这个过程。
    • 终止线程必须进行等待,这样它们才不会进入僵尸状态。
    • 线程本地数据的回收需要对所有线程进行遍历;这必须由管理线程来进行。
    • 如果主线程需要调用 pthread_exit(),那么这个线程就无法结束。主线程要进入睡眠状态,而管理线程的工作就是在所有线程都被杀死之后来唤醒这个主线程。

  • 为了维护线程本地数据和内存,LinuxThreads 使用了进程地址空间的高位内存(就在堆栈地址之下)。

  • 原语的同步是使用信号 来实现的。例如,线程会一直阻塞,直到被信号唤醒为止。

  • 在克隆系统的最初设计之下,LinuxThreads 将每个线程都是作为一个具有惟一进程 ID 的进程实现的。

  • 终止信号可以杀死所有的线程。LinuxThreads 接收到终止信号之后,管理线程就会使用相同的信号杀死所有其他线程(进程)。

  • 根据 LinuxThreads 的设计,如果一个异步信号被发送了,那么管理线程就会将这个信号发送给一个线程。如果这个线程现在阻塞了这个信号,那么这个信号也就会被挂起。这是因为管理线程无法将这个信号发送给进程;相反,每个线程都是作为一个进程在执行。

  • 线程之间的调度是由内核调度器来处理的。

LinuxThreads 及其局限性

LinuxThreads 的设计通常都可以很好地工作;但是在压力很大的应用程序中,它的性能、可伸缩性和可用性都会存在问题。下面让我们来看一下 LinuxThreads 设计的一些局限性:

  • 它使用管理线程来创建线程,并对每个进程所拥有的所有线程进行协调。这增加了创建和销毁线程所需要的开销。

  • 由于它是围绕一个管理线程来设计的,因此会导致很多的上下文切换的开销,这可能会妨碍系统的可伸缩性和性能。

  • 由于管理线程只能在一个 CPU 上运行,因此所执行的同步操作在 SMP 或 NUMA 系统上可能会产生可伸缩性的问题。

  • 由于线程的管理方式,以及每个线程都使用了一个不同的进程 ID,因此 LinuxThreads 与其他与 POSIX 相关的线程库并不兼容。

  • 信号用来实现同步原语,这会影响操作的响应时间。另外,将信号发送到主进程的概念也并不存在。因此,这并不遵守 POSIX 中处理信号的方法。

  • LinuxThreads 中对信号的处理是按照每线程的原则建立的,而不是按照每进程的原则建立的,这是因为每个线程都有一个独立的进程 ID。由于信号被发送给了一个专用的线程,因此信号是串行化的 —— 也就是说,信号是透过这个线程再传递给其他线程的。这与 POSIX 标准对线程进行并行处理的要求形成了鲜明的对比。例如,在 LinuxThreads 中,通过 kill() 所发送的信号被传递到一些单独的线程,而不是集中整体进行处理。这意味着如果有线程阻塞了这个信号,那么 LinuxThreads 就只能对这个线程进行排队,并在线程开放这个信号时在执行处理,而不是像其他没有阻塞信号的线程中一样立即处理这个信号。

  • 由于 LinuxThreads 中的每个线程都是一个进程,因此用户和组 ID 的信息可能对单个进程中的所有线程来说都不是通用的。例如,一个多线程的 setuid()/setgid() 进程对于不同的线程来说可能都是不同的。

  • 有一些情况下,所创建的多线程核心转储中并没有包含所有的线程信息。同样,这种行为也是每个线程都是一个进程这个事实所导致的结果。如果任何线程 发生了问题,我们在系统的核心文件中只能看到这个线程的信息。不过,这种行为主要适用于早期版本的 LinuxThreads 实现。

  • 由于每个线程都是一个单独的进程,因此 /proc 目录中会充满众多的进程项,而这实际上应该是线程。

  • 由于每个线程都是一个进程,因此对每个应用程序只能创建有限数目的线程。例如,在 IA32 系统上,可用进程总数 —— 也就是可以创建的线程总数 —— 是 4,090。

  • 由于计算线程本地数据的方法是基于堆栈地址的位置的,因此对于这些数据的访问速度都很慢。另外一个缺点是用户无法可信地指定堆栈的大小,因为用户可能会意外地将堆栈地址映射到本来要为其他目的所使用的区域上了。按需增长(grow on demand) 的概念(也称为浮动堆栈 的概念)是在 2.4.10 版本的 Linux 内核中实现的。在此之前,LinuxThreads 使用的是固定堆栈。

关于 NPTL

NPTL,或称为 Native POSIX Thread Library,是 Linux 线程的一个新实现,它克服了 LinuxThreads 的缺点,同时也符合 POSIX 的需求。与 LinuxThreads 相比,它在性能和稳定性方面都提供了重大的改进。与 LinuxThreads 一样,NPTL 也实现了一对一的模型。

Ulrich Drepper 和 Ingo Molnar 是 Red Hat 参与 NPTL 设计的两名员工。他们的总体设计目标如下:

  • 这个新线程库应该兼容 POSIX 标准。

  • 这个线程实现应该在具有很多处理器的系统上也能很好地工作。

  • 为一小段任务创建新线程应该具有很低的启动成本。

  • NPTL 线程库应该与 LinuxThreads 是二进制兼容的。注意,为此我们可以使用 LD_ASSUME_KERNEL,这会在本文稍后进行讨论。

  • 这个新线程库应该可以利用 NUMA 支持的优点。

NPTL 的优点

与 LinuxThreads 相比,NPTL 具有很多优点:

  • NPTL 没有使用管理线程。管理线程的一些需求,例如向作为进程一部分的所有线程发送终止信号,是并不需要的;因为内核本身就可以实现这些功能。内核还会处理每个 线程堆栈所使用的内存的回收工作。它甚至还通过在清除父线程之前进行等待,从而实现对所有线程结束的管理,这样可以避免僵尸进程的问题。

  • 由于 NPTL 没有使用管理线程,因此其线程模型在 NUMA 和 SMP 系统上具有更好的可伸缩性和同步机制。

  • 使用 NPTL 线程库与新内核实现,就可以避免使用信号来对线程进行同步了。为了这个目的,NPTL 引入了一种名为futex 的新机制。futex 在共享内存区域上进行工作,因此可以在进程之间进行共享,这样就可以提供进程间 POSIX 同步机制。我们也可以在进程之间共享一个 futex。这种行为使得进程间同步成为可能。实际上,NPTL 包含了一个 PTHREAD_PROCESS_SHARED 宏,使得开发人员可以让用户级进程在不同进程的线程之间共享互斥锁。

  • 由于 NPTL 是 POSIX 兼容的,因此它对信号的处理是按照每进程的原则进行的;getpid() 会为所有的线程返回相同的进程 ID。例如,如果发送了 SIGSTOP 信号,那么整个进程都会停止;使用 LinuxThreads,只有接收到这个信号的线程才会停止。这样可以在基于 NPTL 的应用程序上更好地利用调试器,例如 GDB。

  • 由于在 NPTL 中所有线程都具有一个父进程,因此对父进程汇报的资源使用情况(例如 CPU 和内存百分比)都是对整个进程进行统计的,而不是对一个线程进行统计的。

  • NPTL 线程库所引入的一个实现特性是对 ABI(应用程序二进制接口)的支持。这帮助实现了与 LinuxThreads 的向后兼容性。这个特性是通过使用 LD_ASSUME_KERNEL 实现的,下面就来介绍这个特性。

LD_ASSUME_KERNEL 环境变量

正如上面介绍的一样,ABI 的引入使得可以同时支持 NPTL 和 LinuxThreads 模型。基本上来说,这是通过 ld (一个动态链接器/加载器)来进行处理的,它会决定动态链接到哪个运行时线程库上。

举例来说,下面是 WebSphere® Application Server 对这个变量所使用的一些通用设置;您可以根据自己的需要进行适当的设置:

  • LD_ASSUME_KERNEL=2.4.19:这会覆盖 NPTL 的实现。这种实现通常都表示使用标准的 LinuxThreads 模型,并启用浮动堆栈的特性。
  • LD_ASSUME_KERNEL=2.2.5:这会覆盖 NPTL 的实现。这种实现通常都表示使用 LinuxThreads 模型,同时使用固定堆栈大小。

我们可以使用下面的命令来设置这个变量:

export LD_ASSUME_KERNEL=2.4.19

注意,对于任何 LD_ASSUME_KERNEL 设置的支持都取决于目前所支持的线程库的 ABI 版本。例如,如果线程库并不支持 2.2.5 版本的 ABI,那么用户就不能将 LD_ASSUME_KERNEL 设置为 2.2.5。通常,NPTL 需要 2.4.20,而 LinuxThreads 则需要 2.4.1。

如果您正运行的是一个启用了 NPTL 的 Linux 发行版,但是应用程序却是基于 LinuxThreads 模型来设计的,那么所有这些设置通常都可以使用。

GNU_LIBPTHREAD_VERSION 宏

大部分现代 Linux 发行版都预装了 LinuxThreads 和 NPTL,因此它们提供了一种机制来在二者之间进行切换。要查看您的系统上正在使用的是哪个线程库,请运行下面的命令:

$ getconf GNU_LIBPTHREAD_VERSION

这会产生类似于下面的输出结果:

NPTL 0.34

或者:

linuxthreads-0.10

Linux 发行版所使用的线程模型、glibc 版本和内核版本

表 1 列出了一些流行的 Linux 发行版,以及它们所采用的线程实现的类型、glibc 库和内核版本。

表 1. Linux 发行版及其线程实现
线程实现C 库发行版内核
LinuxThreads 0.7, 0.71 (for libc5)libc 5.xRed Hat 4.2
LinuxThreads 0.7, 0.71 (for glibc 2)glibc 2.0.xRed Hat 5.x
LinuxThreads 0.8glibc 2.1.1Red Hat 6.0
LinuxThreads 0.8glibc 2.1.2Red Hat 6.1 and 6.2
LinuxThreads 0.9
Red Hat 7.22.4.7
LinuxThreads 0.9glibc 2.2.4Red Hat 2.1 AS2.4.9
LinuxThreads 0.10glibc 2.2.93Red Hat 8.02.4.18
NPTL 0.6glibc 2.3Red Hat 9.02.4.20
NPTL 0.61glibc 2.3.2Red Hat 3.0 EL2.4.21
NPTL 2.3.4glibc 2.3.4Red Hat 4.02.6.9
LinuxThreads 0.9glibc 2.2SUSE Linux Enterprise Server 7.12.4.18
LinuxThreads 0.9glibc 2.2.5SUSE Linux Enterprise Server 82.4.21
LinuxThreads 0.9glibc 2.2.5United Linux2.4.21
NPTL 2.3.5glibc 2.3.3SUSE Linux Enterprise Server 92.6.5

注意,从 2.6.x 版本的内核和 glibc 2.3.3 开始,NPTL 所采用的版本号命名约定发生了变化:这个库现在是根据所使用的 glibc 的版本进行编号的。

Java™ 虚拟机(JVM)的支持可能会稍有不同。IBM 的 JVM 可以支持表 1 中 glibc 版本高于 2.1 的大部分发行版。

结束语

LinuxThreads 的限制已经在 NPTL 以及 LinuxThreads 后期的一些版本中得到了克服。例如,最新的 LinuxThreads 实现使用了线程注册来定位线程本地数据;例如在 Intel® 处理器上,它就使用了 %fs 和 %gs 段寄存器来定位访问线程本地数据所使用的虚拟地址。尽管这个结果展示了 LinuxThreads 所采纳的一些修改的改进结果,但是它在更高负载和压力测试中,依然存在很多问题,因为它过分地依赖于一个管理线程,使用它来进行信号处理等操作。

您应该记住,在使用 LinuxThreads 构建库时,需要使用 -D_REENTRANT 编译时标志。这使得库线程是安全的。

最后,也许是最重要的事情,请记住 LinuxThreads 项目的创建者已经不再积极更新它了,他们认为 NPTL 会取代 LinuxThreads。

LinuxThreads 的缺点并不意味着 NPTL 就没有错误。作为一个面向 SMP 的设计,NPTL 也有一些缺点。我曾经看到过在最近的 Red Hat 内核上出现过这样的问题:一个简单线程在单处理器的机器上运行良好,但在 SMP 机器上却挂起了。我相信在 Linux 上还有更多工作要做才能使它具有更好的可伸缩性,从而满足高端应用程序的需求。


参考资料

学习

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。

  • Ulrich Drepper 和 Ingo Molnar 编写的 “The Native POSIX Thread Library for Linux”(PDF)介绍了设计 NPTL 的原因和目标,其中包括了 LinuxThreads 的缺点和 NPTL 的优点。 

  • LinuxThreads FAQ 包含了有关 LinuxThreads 和 NPTL 的常见问题。这对于了解早期的 LinuxThreads 实现的缺点来说是一个很好的资源。 

  • Ulrich Drepper 撰写的 “Explaining LD_ASSUME_KERNEL” 提供了有关这个环境变量的详细介绍。 

  • “Native POSIX Threading Library (NPTL) support” 从 WebSphere 的视角介绍了 LinuxThreads 和 NPTL 之间的区别,并解释了 WebSphere Application Server 如何支持这两种不同的线程模型。 

  • Diagnosis documentation for IBM ports of the JVM 定义了 Java 应用程序在 Linux 上运行时面临问题时所要搜集的诊断信息。 

  • 在 developerWorks Linux 专区 中可以找到为 Linux 开发人员准备的更多资源。 

  • 随时关注 developerWorks 技术事件和网络广播。 

获得产品和技术

  • LinuxThreads README 对 LinuxThreads 概要进行了介绍。 

  • 在您的下一个开发项目中采用 IBM 试用软件,这可以从 developerWorks 上直接下载。 

讨论

  • 通过参与 developerWorks blogs 加入 developerWorks 社区。 

关于作者

Vikram Shukla 具有 6 年使用面向对象语言进行开发和设计的经验,目前是位于印度 Banglore 的 IBM Java Technology Center 的一名资深软件工程师,负责对 IBM JVM on Linux 进行支持。

转自:http://blog.chinaunix.net/uid-20556054-id-3068081.html

posted @ 2012-12-18 13:52 鑫龙 阅读(410) | 评论 (0)编辑 收藏

Native POSIX Thread Library

维基百科,自由的百科全书

Native POSIX Thread LibraryNPTL)是一个能够使使用POSIX Threads编写的程序在Linux内核上更有效地运行的软件。

测试表明,NPTL能够成功地在IA-32平台上在两秒种内生成100,000个线程;相应的没有NPTL的内核将耗费15分钟左右。

历史

Linux内核2.6出现之前进程是(最小)可调度的对象,当时的Linux不真正支持线程。但是Linux内核有一个系统调用指令clone(),这个指令产生一个呼叫调用的进程的复件,而且这个复件与原进程使用同一地址空间。LinuxThreads计划使用这个系统调用来提供一个内核级的线程支持。但是这个解决方法与真正的POSIX标准有一些不相容的地方,尤其是在信号处理、进程调度和进程间同步原语方面。

要提高LinuxThreads的效应很明显需要提供内核支持以及必须重写线程函式库。为了解决这个问题出现了两个互相竞争的项目:一个IBM的组的项目叫做NGPTNext Generation POSIX Threads,下一代POSIX线程),另一个组是由Red Hat程序员组成的。2003年中NGPT被放弃,几乎与此同时NPTL公布了。

NPTL首次是随Red Hat Linux 9发表的。此前老式的Linux POSIX线程偶尔会发生系统无法产生线程的毛病,这个毛病的原因是因为在新线程开始的时候系统没有借机先占。当时的Windows系统对这个问题的解决比较好。Red Hat在关于Red Hat Linux 9上的Java的网页上发表了一篇文章称NPTL解决了这个问题。

从第3版开始NPTLRed Hat Enterprise Linux的一部分,从Linux内核2.6开始它被纳入内核。目前它完全被结合入GNU C 函式库。

设计

NPTL的解决方法与LinuxThreads类似,内核看到的首要抽象依然是一个进程,新线程是通过clone()系统调用产生的。但是NPTL需要特殊的内核支持来解决同步的原始类型之间互相竞争的状况。在这种情况下线程必须能够入眠和再复苏。用来完成这个任务的原始类型叫做futex

NPTL是一个所谓的1×1线程函式库。用户产生的线程与内核能够分配的物件之间的联系是一对一的。这是所有线程程式中最简单的。

转自http://zh.wikipedia.org/wiki/Native_POSIX_Thread_Library#cite_note-1

转自:http://blog.chinaunix.net/uid-20556054-id-3068071.html

posted @ 2012-12-18 13:50 鑫龙 阅读(462) | 评论 (0)编辑 收藏

     摘要: (转自http://programmerdigest.cn/2010/08/1096.html,其中的实验数据重新做过测试,在语言上也有所修改)在Unix上编程采用多线程还是多进程的争执由来已久,这种争执最常见到在B/S通讯中服务端并发技术 的选型上,比如WEB服务器技术中,Apache是采用多进程的(perfork模式,每客户连接对应一个进程,每进程中只存在唯一一个执行线 程),Java的Web...  阅读全文

posted @ 2012-12-18 13:49 鑫龙 阅读(628) | 评论 (0)编辑 收藏

关于多进程和多线程,教科书上最经典的一句话是“进程是资源分配的最小单位,线程是CPU调度的最小单位”。这句话应付考试基本上够了,但如果在工作中遇到类似的选择问题,那就没有那么简单了,选的不好,会让你深受其害。
经常在网络上看到有XDJM问“多进程好还是多线程好?”、"Linux下用多进程还是多线程?"等等期望一劳永逸的问题,只能说:没有最好,只有更好,根据实际情况来判断,哪个更加合适就是哪个好。
我们按照多个不同的维度,来看看多进程和多线程的对比(注:因为是感性的比较,因此都是相对的,不是说一个好得不得了,另一个差的无法忍受)

维度

多进程

多线程

总结

数据共享、同步

数据是分开的:共享复杂,需要用IPC;同步简单

多线程共享进程数据:共享简单;同步复杂

各有优势

内存、CPU

占用内存多,切换复杂,CPU利用率低

占用内存少,切换简单,CPU利用率高

线程占优

创建销毁、切换

创建销毁、切换复杂,速度慢 

创建销毁、切换简单,速度快 

线程占优 

编程调试

编程简单,调试简单

编程复杂,调试复杂

进程占优 

可靠性

进程间不会相互影响 

一个线程挂掉将导致整个进程挂掉

进程占优

分布式 

适应于多核、多机分布 ;如果一台机器不够,扩展到多台机器比较简单

适应于多核分布

进程占优



1)需要频繁创建销毁的优先用线程。
   实例:web服务器。来一个建立一个线程,断了就销毁线程。要是用进程,创建和销毁的代价是很难承受的。
2)需要进行大量计算的优先使用线程。
   所谓大量计算,当然就是要消耗很多cpu,切换频繁了,这种情况先线程是最合适的。
   实例:图像处理、算法处理
3)强相关的处理用线程,若相关的处理用进程。
   什么叫强相关、弱相关?理论上很难定义,给个简单的例子就明白了。
   一般的server需要完成如下任务:消息收发和消息处理。消息收发和消息处理就是弱相关的任务,而消息处理里面可能又分为消息解码、业务处理,这两个任务相对来说相关性就要强多了。因此消息收发和消息处理可以分进程设计,消息解码和业务处理可以分线程设计。
4)可能扩展到多机分布的用进程,多核分布的用线程。
5)都满足需求的情况下,用你最熟悉、最拿手的方式。
   至于”数据共享、同步“、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍,只能说:没有明确的选择方法。一般有一个选择原则:如果多进程和多线程都能够满足要求,那么选择你最熟悉、最拿手的那个。
需要提醒的是:虽然有这么多的选择原则,但实际应用中都是“进程+线程”的结合方式,千万不要真的陷入一种非此即彼的误区。

转自:http://software.intel.com/zh-cn/blogs/2010/07/20/400004478/ 

转自:http://blog.chinaunix.net/uid-20556054-id-3061450.html

posted @ 2012-12-18 13:47 鑫龙 阅读(293) | 评论 (0)编辑 收藏

进程(英语:Process,中国大陆译作进程,台湾译作行程) 是具有一定独立功能的程序关于某个数据集合上的一次运行活动,是系统进行资源分配和调度的一个独立单位。
程序是一组指令的有序集合,它本身没有任何运行的含义,只是一个静态实体。进程是程序在某个数据集上的执行,是一个动态实体(进程本身不会运行,是线程的容器。)。它因创建而产生,因调度而运行,因等待资源或事件而被处于等待状态,因完成任务而被撤消,反映了一个程序在一定的数据集上运行的全部动态过程。
若干进程有可能与同一个程序相关系,且每个进程皆可以同步(循序)或不同步(平行)的方式独立运行。进程为现今分时系统的基本运作单位。


线程
(英语:thread,台湾译为运行绪),操作系统技术中的术语,是操作系统能够进行运算调度的最小单位。它被包涵在进程之中,一条线程指的是进程中一个单一顺序的控制流,一个进程中可以并发多个线程,每条线程并行执行不同的任务。在Unix System V及SunOS中也被称为轻量进程(lightweight processes),但轻量进程更多指内核线程(kernel thread),而把用户线程(user thread)称为线程。

线程是独立调度和分派的基本单位。线程可以操作系统内核调度的内核线程,如Win32 线程;由用户进程自行调度的用户线程,如Linux Portable Thread; 或者由内核与用户进程,如Windows 7的线程,进行混合调度。

同一进程中的多条线程将共享该进程中的全部系统资源,如虚拟地址空间,文件描述符和信号处理等等。但同一进程中的多个线程有各自的调用栈(call stack),自己的寄存器环境(register context),自己的线程本地存储(thread-local storage)。

一个进程可以有很多线程,每条线程并行执行不同的任务。

在多核或多CPU,或支持Hyper-threading的CPU上使用多线程程序设计的好处是显而易见,即提高了程序的执行吞吐率。在单CPU单核的计算机上,使用多线程技术,也可以把进程中负责IO处理、人机交互而常备阻塞的部分与密集计算的部分分开来执行,编写专门的workhorse线程执行密集计算,从而提高了程序的执行效率。(摘自:http://zh.wikipedia.org/wiki/线程)


进程是资源分配的最小单位,线程是CPU调度的最小单位。线程和进程的区别在于,子进程和父进程有不同的代码和数据空间,而多个线程则共享数据空间,每个线程有自己的执行堆栈和程序计数器为其执行上下文.多线程主要是为了节约CPU时间,发挥利用,根据具体情况而定. 线程的运行中需要使用计算机的内存资源和CPU。


多进程: 进程是程序在计算机上的一次执行活动。当你运行一个程序,你就启动了一个进程。显然,程序是死的(静态的),进程是活的(动态的)。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就是处于运行状态下的操作系统本身;所有由用户启动的进程都是用户进程。进程是操作系统进行资源分配的单位。 进程又被细化为线程,也就是一个进程下有多个能独立运行的更小的单位。在同一个时间里,同一个计算机系统中如果允许两个或两个以上的进程处于运行状态,这便是多任务。现代的操作系统几乎都是多任务操作系统,能够同时管理多个进程的运行。 多任务带来的好处是明显的,比如你可以边听mp3边上网,与此同时甚至可以将下载的文档打印出来,而这些任务之间丝毫不会相互干扰。那么这里就涉及到并行的问题,俗话说,一心不能二用,这对计算机也一样,原则上一个CPU只能分配给一个进程,以便运行这个进程。我们通常使用的计算机中只有一个CPU,也就是说只有一颗心,要让它一心多用,同时运行多个进程,就必须使用并发技术。实现并发技术相当复杂,最容易理解的是“时间片轮转进程调度算法”,它的思想简单介绍如下:在操作系统的管理下,所有正在运行的进程轮流使用CPU,每个进程允许占用CPU的时间非常短(比如10毫秒),这样用户根本感觉不出来 CPU是在轮流为多个进程服务,就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU。 如果一台计算机有多个CPU,情况就不同了,如果进程数小于CPU数,则不同的进程可以分配给不同的CPU来运行,这样,多个进程就是真正同时运行的,这便是并行。但如果进程数大于CPU数,则仍然需要使用并发技术。 进行CPU分配是以线程为单位的,一个进程可能由多个线程组成,这时情况更加复杂,但简单地说,有如下关系: 

总线程数<= CPU数量:并行运行 

总线程数> CPU数量:并发运行 

并行运行的效率显然高于并发运行,所以在多CPU的计算机中,多任务的效率比较高。但是,如果在多CPU计算机中只运行一个进程(线程),就不能发挥多CPU的优势。 这里涉及到多任务操作系统的问题,多任务操作系统(如Windows)的基本原理是:操作系统将CPU的时间片分配给多个线程,每个线程在操作系统指定的时间片内完成(注意,这里的多个线程是分属于不同进程的).操作系统不断的从一个线程的执行切换到另一个线程的执行,如此往复,宏观上看来,就好像是多个线程在一起执行.由于这多个线程分属于不同的进程,因此在我们看来,就好像是多个进程在同时执行,这样就实现了多任务.(摘自:http://zhidao.baidu.com/question/2601473)


多线程
:在计算机编程中,一个基本的概念就是同时对多个任务加以控制。许多程序设计问题都要求程序能够停下手头的工作,改为处理其他一些问题,再返回主进程。可以通过多种途径达到这个目的。最开始的时候,那些掌握机器低级语言的程序员编写一些“中断服务例程”,主进程的暂停是通过硬件级的中断实现的。尽管这是一种有用的方法,但编出的程序很难移植,由此造成了另一类的代价高昂问题。中断对那些实时性很强的任务来说是很有必要的。但对于其他许多问题,只要求将问题划分进入独立运行的程序片断中,使整个程序能更迅速地响应用户的请求。  
最开始,线程只是用于分配单个处理器的处理时间的一种工具。但假如操作系统本身支持多个处理器,那么每个线程都可分配给一个不同的处理器,真正进入“并行运算”状态。从程序设计语言的角度看,多线程操作最有价值的特性之一就是程序员不必关心到底使用了多少个处理器。程序在逻辑意义上被分割为数个线程;假如机器本身安装了多个处理器,那么程序会运行得更快,毋需作出任何特殊的调校。根据前面的论述,大家可能感觉线程处理非常简单。但必须注意一个问题:共享资源!如果有多个线程同时运行,而且它们试图访问相同的资源,就会遇到一个问题。举个例子来说,两个线程不能将信息同时发送给一台打印机。为解决这个问题,对那些可共享的资源来说(比如打印机),它们在使用期间必须进入锁定状态。所以一个线程可将资源锁定,在完成了它的任务后,再解开(释放)这个锁,使其他线程可以接着使用同样的资源。 
多线程是为了同步完成多项任务,不是为了提高运行效率,而是为了提高资源使用效率来提高系统的效率。线程是在同一时间需要完成多项任务的时候实现的。
一个采用了多线程技术的应用程序可以更好地利用系统资源。其主要优势在于充分利用了CPU的空闲时间片,可以用尽可能少的时间来对用户的要求做出响应,使得进程的整体运行效率得到较大提高,同时增强了应用程序的灵活性。更为重要的是,由于同一进程的所有线程是共享同一内存,所以不需要特殊的数据传送机制,不需要建立共享存储区或共享文件,从而使得不同任务之间的协调操作与运行、数据的交互、资源的分配等问题更加易于解决(摘自:http://baike.baidu.com/view/65706.htm)
通常由操作系统负责多个线程的调度和执行。


进程间通信IPCInter-Process Communication),指至少两个进程线程间传送数据或信号的一些技术或方法。进程是计算机系统分配资源的最小单位。每个进程都有自己的一部分独立的系统资源,彼此是隔离的。为了能使不同的进程互相访问资源并进行协调工作,才有了进程间通信。这些进程可以运行在同一计算机上或网络连接的不同计算机上。

进程间通信技术包括消息传递、同步、共享内存和远程过程调用。IPC是一种标准的Unix通信机制。

使用IPC 的理由:

  • 信息共享
  • 加速;
  • 模块化;
  • 方便以及
  • 私有权分离.

主要的 IPC 方法

方法

提供方(操作系统或其他环境)

文件

多数操作系统

信号

多数操作系统

Socket

多数操作系统

消息队列(en:Message queue)

多数操作系统

管道(en:Pipe)

所有的 POSIX systems, Windows.

具名管道(en:Named Pipe)

所有的 POSIX 系统, Windows.

信号量(en:Semaphore)

所有的 POSIX 系统, Windows.

共享内存

所有的 POSIX 系统, Windows.

Message passing(en:Message passing)
(
不共享)

用于 MPI规范,Java RMI, CORBA, MSMQ, MailSlot以及其他.

Memory-mapped file(en:Memory-mapped file)

所有的 POSIX 系统, Windows.

(摘自:http://zh.wikipedia.org/wiki/行程間通訊) 

转自:http://blog.chinaunix.net/uid-20556054-id-3060696.html

posted @ 2012-12-18 13:44 鑫龙 阅读(532) | 评论 (0)编辑 收藏

今天突然想比较一下 write() 和 writev() 的性能, 网上google了半天, 竟然没有发现一点有关的数据信息, 自己就测试了一下。

平台如下:

CentOS 5.2 Linux kernel 2.6.18-92.e15

CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz

Disk: 7200 rpm

测试的想法是: 对于writev(), 如果有10 个buffer, 并且buffer的大小是1kb,  那么我就先依次调用write() 10 次, 每次写1KB 到同一个文件, 记录下时间, 然后记录下用writev()的时间。 最后, 以write()为baseline, 计算writev()所占的%, 如果%越小, 证明writev() 的性能就越好。

做了两组测试,

第一组, 固定buffer 的个数(10, 100, 1000), 依次增加buffer的大小, 从1KB -- 1024KB, 数据如下, (基准线为相应write()的数据)

例如, 10 个buffer, 每个buffer size 是1KB。 write() 耗时0.092 ms, writev() 耗时0.098 ms, 图中的数据即为 1.067 (write_v10, 1KB)

图一writev和write性能比较(转) - 光明磊落 - 光明磊落的博客

 

第二组, 固定buffer大小(1KB, 2KB, 8KB), 依次增加buffer的数目, 从 200 -- 8000, 数据如下 (基准线为相应write()的数据)

图二

writev和write性能比较(转) - 光明磊落 - 光明磊落的博客

第一组数据显示:1.  随着buffer的增大 ( > 64KB), writev()的性能开始跟write()持平; 2. 如果buffer的个数过小 , writev()的性能是低于write()的。 从图一可以看到,  在buffer size 小于1024KB 时, writev() 使用10 个buffer的性能要低于100 和1000。

第二组数据显示: 1. 当保持buffer size一定情况下, 增加buffer的个数 (< 2000), writev() 的性能稳定在70%左右; 2. 增加buffer size, 将会降低writev()的性能。 当buffer为8KB 时, writev() 所用时间基本上都为相应write()时间的80%, 性能的提高明显不如1KB 和 2KB。3. 当buffer的个数超过2000, 并且buffer size 大于2KB, writev()性能将远不如write()。

结论:

writev() 应使用在small write intensive 的workload中, buffer size 应控制在 2KB 以下, 同时buffer的数目不要超过IOV_MAX, 否则 writev() 并不会带来性能的提高。 

 

现在, 所要研究的问题是对于不同的workload, 如何快速的确定writev()中buffer的个数和大小, 从而达到较好performance。

Saturday, May 09, 2009  8:50:48 PM

posted @ 2012-12-18 11:33 鑫龙 阅读(1415) | 评论 (0)编辑 收藏

     首先,建议性锁和强制性锁并不是真正存在的锁,而是一种能对诸如记录锁、文件锁效果产生影响的两种机制。

1.建议性锁机制是这样规定的:每个使用文件的进程都要主动检查该文件是否有锁存在,当然都是通过具体锁的API,比如fctl记录锁F_GETTLK来主动检查是否有锁存在。如果有锁存在并被排斥,那么就主动保证不再进行接下来的IO操作。如果每一个进程都主动进行检查,并主动保证,那么就说这些进程都以一致性的方法处理锁,(这里的一致性方法就是之前说的两个主动)。但是这种一致性方法依赖于编写进程程序员的素质,也许有的程序员编写的进程程序遵守这个一致性方法,有的不遵守。不遵守的程序员编写的进程程序会怎么做呢?也许会不主动判断这个文件有没有加上文件锁或记录锁,就直接对这个文件进行IO操作。此时这种有破坏性的IO操作会不会成功呢?如果是在建议性锁的机制下,这种破坏性的IO就会成功。因为锁只是建议性存在的,并不强制执行。内核和系统总体上都坚持不使用建议性锁机制,它们依靠程序员遵守这个规定。(Linux默认是采用建议性锁)

2.强制性锁机制是这样规定的: 所有记录或文件锁功能内核执行的。上述提到的破坏性IO操作会被内核禁止。当文件被上锁来进行读写操作时,在锁定该文件的进程释放该锁之前,内核会强制阻止任何对该文件的读或写违规访问,每次读或写访问都得检查锁是否存在。也就是强制性锁机制,让锁变得名副其实,真正达到了锁的效果,而不是像建议性锁机制那样只是个纸老虎。= =!
   设置强制性文件锁的方式比较特别:

   chmod g+s <filename>
   chmod g-x <filename>

   这是形象的表示,实际编程中应该通过chmod()函数一步完成。不能对目录、可执行文件设置强制性锁。 

3.贴出网上搜到的解释

例1,我有几个进程(不一定有亲缘关系)都先通过fctnl锁机制来判断再操作文件,这个就叫一致的方法。参见[2] 
但是,如果同时,又有个流氓进程,管它3721,冲上去,直接open, write一堆操作。 
这时候那几个先fcntl 再操作的进程对这种方式无能为力,这样就叫不一致。文件最后的状态就不定了。 
正因为这种锁约束不了其它的访问方式,所以叫建议行锁。强制性锁需要内核支持的,对read, write, open都会检查锁。
例2,所谓建议性锁就是假定人们都会遵守某些规则去干一件事。例如,人与车看到红灯都会停,而看到绿灯才会继续走,我们可以称红绿等为建议锁。但这只是一种规则而已,你并不防止某些人强闯红灯。而强制性锁是你想闯红灯也闯不了。

posted @ 2012-12-17 12:24 鑫龙 阅读(1904) | 评论 (0)编辑 收藏

     摘要: 这几天开始拜读侯捷先生和孟岩先生的译作《C++标准程序库:自修教程与参考手册》 。两位先生确实译功上乘,读得很顺。但是读到P55页关于auto_ptr_ref的讨论,却百思不得其解:为什么需要引入auto_ptr_ref这个辅助类呢? 从书中描述来看,仿佛与拷贝构造函数 、右值 、类型转换 有关。于是,结合auto_ptr的源代码,google之、...  阅读全文

posted @ 2012-12-16 16:06 鑫龙 阅读(244) | 评论 (0)编辑 收藏

左值右值

左值(lvalue)和右值(rvalue)是编程中两个非常基本的概念,但是也非常容易让人误解,看了很多文章,自我感觉真正将这个问题讲的很透彻的文章还没有看见,所以自告奋勇来尝试一下。如果左值右值的概念不是非常清楚的话,它们迟早会像拦路虎一样跳出来,让你烦心不已,就像玩电脑游戏的时候每隔一段时间总有那么几个地雷考验你的耐性,如果一次把所有地雷扫尽就好了。:)

左值(lvalue)和右值(rvalue)最先来源于编译理论(感谢南大小百合的programs)。在C语言中表示位于赋值运算符两侧的两个值,左边的就叫左值,右边的就叫右值。比如:

int ii = 5;//ii是左值,5是右值

int jj = ii;//jj是左值,ii是右值

上面表明,左值肯定可以作为右值使用,但反之则不然。左值和右值的最早区别就在于能否改变。左值是可以变的,右值不能变。【注1

1:这一点在C++中已经猪羊变色,不再成立。拱猪游戏还是挺好玩的,我还真抓过好几次全红心,不过真的好险。:)

在很多文章中提到,在C++中,左值更多的指的是可以定位,即有地址的值,而右值没有地址。【注2

2:这一点仍然不准确,我在程序中生成一个临时右值std::vector(),你能够说它没有地址吗?难道它是没有肉体的鬼魂或幽灵?它是有地址的,而且它也是绝对的右值。

在现代C++中,现在左值和右值基本上已经失去它们原本所具有的意义,对于左值表达式,通过具体名字和引用(pointer or reference)来指定一个对象。非左值就是右值。我来下一个定义:

左值表示程序中必须有一个特定的名字引用到这个值。

右值表示程序中没有一个特定的名字引用到这个值。

跟它们是否可以改变,是否在栈或堆(stack or heap)中有地址毫无关系。

1.左值

在下面的代码中:

int ii = 5;

int const jj = ii;

int a[5];

a[0] = 100;

*(a+3) = 200;

int const& max( int const& a, int const& b ) //call by reference

{

      return a > b ? a : b;

}

int& fun(int& a) //call by reference

{

      a += 5;

   return a;

}

iijja[0]*(a+3),还有函数max的返回值比如max(ii, jj),【注3】函数fun的返回值fun(ii)都是左值。,它们都是有特定的引用名字的值。iijja[0]*(a+3)max(ii, jj)fun(ii)分别就是它们的名字。

3:在这里有一个不太容易分清楚的盲点。那就是有人会问max(8, 9)到达是左值还是右值,C++标准规定常量引用(reference to const)可以引用到右值,所以max(8, 9)似乎应该是右值,不过不管它是左值,还是右值,我们都不能试图去改变它。为了与前面的概念一致,我认为它是左值,不可改变的常量左值。

左值有不能改变的,即被const所修饰的左值,比如上面的jjmax(ii, jj)都是被常量(const)魔咒所困住的左值。

没有被const困住的左值当然是可以改变的,比如下面的代码都是成立的:

ii = 600;

a[0] = 700;

fun(ii) = 800; //OK!

我们的眼睛没有问题,fun(ii) = 800;完全正确,因为它是可以改变的左值。所以我们看STL的源码,就会理解std::vector中的重载operator[]运算符的返回值为什么要写成引用,因为operator[]必须返回左值。

 

2.右值

没有特定名字的值是右值。先看下面的代码:

std::list();

std::string(“It is a rvalue!”);

int fun1() //call by value

{

      

}

int* fun2() //call by reference

{

      

}

其中std::list()std::string(“It is a rvalue!”),函数fun1的返回值fun1(),函数fun2的返回值fun2()都是右值,它们的值都没有特定的名字去引用。也许有人会奇怪,fun2()也是右值?最前面的max(a,b)不是左值吗?

请看清楚,函数fun2的返回值是pointerpointer也是call by value,而函数max的返回值是referencereferencecall by reference。所以说C++中引入reference不仅仅是为了方便,它也是一种必须。【注4

4Scott Meyer写的《More Effective C++》的条款1专门讲了pointerreference的区别,写的很好,辨别的非常清楚。

fun2()是右值,但 *fun2()却是左值,就跟经常看到的*p一样,所以看C++库代码的时候,会发现重载operator*的函数返回值是reference

当然我还遗漏了一种右值,那就是字面上的(literal)值,比如58.23’a’等等理所当然的都是右值。

右值最初出现的时候,一个最大的特征就是不可改变。但就跟我们的道德标准一样,时代不同了,标准也变化了,以前的三纲五常早已经被扔到历史的垃圾堆里面了。

C++中有可以改变的右值,而且这个特性还非常有用。那就是用户自定义的类(class)的构造函数生成的临时对象。比如:

std::vector(9)std::deque(),……都是可以改变的右值。在Herb Sutter的《More Exceptional C++》中的条款7page51页有这样几行代码:

// Example 7-2(b): The right way to shrink-to-fit a vector.

vector<Customer> c( 10000 );

// ...now c.capacity() >= 10000...

// erase all but the first 10 elements

c.erase( c.begin()+10, c.end() );

// the following line does shrink c's

// internal buffer to fit (or close)

vector<Customer>( c ).swap( c );

// ...now c.capacity() == c.size(), or

// perhaps a little more than c.size()

认真看几遍,你会发现但vector的大小增大到一定程度,你又用不着这么多空间的时候,你会想办法把它收缩到最合适的大小,但利用别的办法比如调用成员函数reserve()都无法办到,这个时候就必须利用右值可以改变这个性质了。

vector<Customer>( c ).swap( c );这行代码就是点睛之处。

首先使用复制构造函数生成临时右值vector<Customer>( c ),这个右值正好是合适大小,然后和c交换【注5】,c就变成合适大小了,最后在整个表达式结束的时候,这个临时右值析构归还内存空间。真是绅士一般的优雅!

5:这个时候这个临时右值就发生了改变。

如果还不理解,可以看看书,或者直接看库的源代码。

至于为什么会这样?我思考了一下,我想是这样的,我们看类(class)的数据布置结构,会发现它的每一个数据成员都是有名字的,我想编译器在编译的过程中,都会生成一个外部不所知的对这个临时对象右值的名字引用,但需要改变这个临时对象的时候,这个名字就用上了。比如:

class Point

{

public: //纯粹为了方便,我把数据成员公开,现实中尽量不要这样用

      int x, y ,z;

      ……//其他各种成员函数

};

我们现在就可以改变右值,用到了匿名的引用名字。

Point().x = 6;//改变了右值

Point().y = 6;//同意改变了右值,不过注意,这个右值跟上面的不是同一个。

总结

左值和右值的真正区别我想就是这些了,左值表示有特定的名字引用,而右值没有特定的名字引用。当然我仍然会有疏忽,希望大家能够提醒我,指正我的不足。

前两天看Herb Sutter从邮件中寄来的新文章(我订阅他的新文章邮件通知),一篇是讲Tuple数据结构的,没有什么新意,以前好像看过,还有一篇名字是:(MostlyPrivate,地址为http://www.cuj.com/documents/s=8273/cujcexp2107sutter/ 内容本身并不深,但看完文章,发现随处可见C++的波诡云谲,又会对什么叫袖里乾坤,滴水藏海多一份感性认识。

在下一篇文章我想从不同于一般的角度,从自己的经历谈谈在校毕业生在IT行业怎样找工作,我想会让所有读者都有一些思考,不仅仅是求职者。题目我已经想好了,就叫《扮虎吃猪》,不过现在我有一些别的事情要忙,所以可能会让大家等几天。

转载请注明来源,谢谢!

吴桐写于2003.6.20

最近修改2003.6.21

转自:
http://blog.csdn.net/csdnji/article/details/169200

posted @ 2012-12-16 15:08 鑫龙 阅读(292) | 评论 (0)编辑 收藏

习惯了这样写,但有时候会反问下自己为什么要const和&?
1.为什么要&?
答:&是必须的。
如果它不是引用,在传递参数时,会产生一个局部变量做参数,而这个局部变量的构造又要调copy构造函数一次,....那就子子孙孙无穷匮了....
但如果是引用,在传递参数时候,局部变量只需要绑定原变量,而不需要再一次调用copy构造函数。

2.为什么要const?
答:const不是必须的。
构造函数是用引用方式传递复制对象,引用方式传递的是地址,因此在构造函数内对该引用的修改会影响源对象。而你在用对象a1构造a2时,自然不希望复制构造函数会改变a1的内容,因此要防止复制构造函数内部修改该引用,所以一般用const声明。加不加const还是需要看copy构造的行为,比如std::auto_ptr的构造函数,就没有const,因为它要获得原有对象指针的拥有权。

posted @ 2012-12-16 14:52 鑫龙 阅读(588) | 评论 (0)编辑 收藏

仅列出标题
共20页: First 9 10 11 12 13 14 15 16 17 Last