设计_Linux多线程编程FAQ

更新时间:2023-06-17 18:35:43 阅读: 评论:0

多线程FAQ
美丽的星期天线程    1
Q:linux线程实现的版本有哪些?    1
Q:linux可以开多少线程?    1
Q:为什么我调用exit()退出程序会出core?    2
Q:ulib提供了一套线程库(ul_thr.h),封装了pthread API,它有什么好处?    2
Q:多线程程序如何调试?    2
线程编程模型    2
Q:百度有哪些常用的线程编程模型,为什么这样用?    2
Q:服务线程池里的线程如何获取客户端请求?    3
中秋节快乐 英语Q:accept已经保证了线程安全,为什么还要对accept加锁?    3
一年级家长会班主任发言稿
共享数据和线程锁    3
Q:我们经常说线程锁操作的开销很大,这个开销指的是什么,到底有多大?    3
Q:什么是锁的粒度?    3
Q:linux提供读写锁吗,如何使用?    4
Q:什么是线程安全的函数?    4
Q:errno是线程安全的吗?    4
Q:C标准输入输出流(STDIO)是线程安全的吗?    4
杂项    4
Q:什么是线程专有数据?    4
Q:线程与信号?    5
Q:信号量还是线程锁+条件变量?    5
Q:SMP、CMP对多线程应用有什么影响?    5
Q:相关的参考资料有哪些?    5
冷山下载线程
新视野大学英语2读写教程答案Q:linux线程实现的版本有哪些?
A:linux的线程遵守POSIX线程标准(pthreads),目前主要有两个版本:
1. LinuxThreads. 1996年由Xavier Leroy实现,基本上实现POSIX 1003.1c,是目前广泛使用的版本。也是我们公司大部分机器上使用的线程版本。
2. NPTL. Native Posix Thread Library由Ulrich Drepper和Ingo Molnar实现。NPTL比LinuxThreads性能更好,也更接近pthreads标准。NPTL已经取代LinuxThreads成为 glibc 的首选线程库,但是NPTL需要2.6内核新特性,在2.4内核系统里无法使用。
关于LinuxThreads与NPTL的比较,可以在装有2.6内核的系统man pthreads。
Q:linux可以开多少线程?
A:限制来自以下几个方面:1. 库中PTHREAD_THREADS_MAX缺省定义为1024。 2. 系统和用户最大进程数限制(ulimit)3. 线程栈地址空间限制。缺省8M,2G地址空间只能容纳最多256个线程。
在32位的系统中,不建议开过多的线程,可以算一下,100个线程就要用掉地址空间800M,地址空间一共就只有2G,用在其它地方会更有用。slip away
Q:为什么我调用exit()退出程序会出core?
A:这是LinuxThreads实现的问题,一个线程退出释放了进程的资源(主要是地址空间),但是这时还有其它线程在运行、访问资源就会出现段错误,出core。这个问题可以通过把exit()替换为向本进程发SIGKILL来解决,但是如果程序中使用了STDIO,这样做可能导致写下去的数据不完整。
这是LinuxThreads实现的一个缺点,在NPTL实现里不会有这样的问题出现。
Q:ulib提供了一套线程库(ul_thr.h),封装了pthread API,它有什么好处?
A: pthreads设计者认为传统的报错方式不好,因而引入了一种全新的报错方式,没有使用errno变量,直接把错误号作为返回值。这是一个编程中要特别注意的地方。
instructions然而,ul_thr的设计者则认为pthreads的报错方式与其它库函数不同,容易混淆,因此,封装了一个和老的报错方式一致的版本,那就是ul_thr。另外,ul_thr还会在调用出错的情况下,自动打印一条warning日志。
是pthread API还是ul_thr,可以按自己的需要来选择。
Q:多线程程序如何调试?
A: GDB支持多线程程序的调试。首先,和单线程程序一样,设置的断点无论那一个线程执行到,GDB都会断到,并且会告诉你被断的是哪一个线程。
    其次,GDB有info thread命令可以打印出进程里所有的线程。用thread THREAD_NO命令可以切换到指定线程。注意一点:LinuxThreads实现里一定会有一个管理线程在,一般是第2个,所以实际显示的线程数一定会比你开的线程多1个。
    我们的程序大多都要网络通信,对超时很敏感,所以有时候GDB没办法用。这时候多打些debug日志就显得很重要了。
线程编程模型
Q:百度有哪些常用的线程编程模型,为什么这样用?
A: 由于我们公司服务模块拆分很细致,所以绝大部分模块都不需要复杂的线程并发模型,一般我们使用的就是线程池:直接在程序启动时起一池线程提供服务,共享数据通过加线程锁来同步。目前来看,这种方式简单并且高效。
因此,如非必要,请不要使用复杂的线程模型。
Q:服务线程池里的线程如何获取客户端请求?
A:对于请求的获取方式,主要有两种:
一种是所有服务线程同时accept,服务线程拿到一个连接就为这个连接服务,直到连接被关闭。这是目前用的最多的一种方式。flee
另一种是pendingpool,一个线程负责监听客户端请求(包括连接请求),把有请求的fd放到消息队列里,所有服务线程从消息队列里拿请求去处理。关于pendingpool的使用,详见网络编程FAQ。
Q:accept已经保证了线程安全,为什么还要对accept加锁?
A:accept提供了一种机制,对同时accept的线程排队,但是accept安全性问题实际上都没有一个比较明确的说法和验证。这个问题确实由来已久,主要是Apache的所谓“thundering herd”(在2.4内核已经解决)引发了这些讨论。我们很多程序对Accept加锁,是希望能规避可能的风险,把控制权由应用程序把握。
共享数据和线程锁
Q:我们经常说线程锁操作的开销很大,这个开销指的是什么,到底有多大?
A: 线程锁操作的开销主要来自两个方面:一方面锁操作消耗CPU,另一方面锁操作耗时。这种开销一方面源于内核对锁的管理操作(如排队等),另一方面源于锁操作引起的频繁进程/线程切换。另外,LinuxThreads用信号来实现线程锁,开销相应比NPTL要更大
一些。
    一般的,锁操作开销与malloc在一个量级:比算数运算(指各种整数及浮点运算)慢得多,但比磁盘和网络I/O快得多。因此,在I/O密集的程序里,I/O是性能的瓶颈,锁操作又不对I/O造成影响,因此适量的锁操作对性能影响不大。而在CPU密集的程序里,锁操作抢CPU,并且拖慢请求处理的速度,因此开销比较显著。
    了解线程锁的开销问题对性能优化是有指导意义的。对于I/O密集型的模块,重点在于I/O的优化,如果有利于减少I/O或者增加I/O的并发度,可以考虑把锁的粒度放小。而对于CPU密集型的模块,应该严格控制锁的使用,能不用锁的一定不用,必须用锁的考虑锁的粒度适当大一些,以减少锁操作次数。
Q:什么是锁的粒度?
A:主要有两个方面:
1. 纵向,就是被锁的区域(临界区)有多少代码。这个当然不是指代码行数。而是说有多少计算量,有多少I/O操作,执行一次要多少时间。它描述的是多大规模的操作被串行。
2. 横向,就是一个锁锁住了多少资源。拿磁盘I/O来说,一个锁是锁了所有的文件、还是几个文件或者是一个文件,甚至是一个文件中的一个区域,文件有多大,区域有多大?它描述的是有多少资源被串行访问。
锁的粒度越小越有利于提高程序的并发度,但锁操作本身的开销越大。
Q:linux提供读写锁吗?
A:linux提供了pthread rwlock,在2.4内核就有,但是man page找不到。在程序里定义
#define _XOPEN_SOURCE 500
就可以使用了。
Q:什么是线程安全的函数?
dictionaryA:在ANSI和POSIX 1003.1-1990开发时没有考虑到线程,因此目前的标准库函数有一些不是线程安全的。这主要有两类:一类是内部使用静态变量并作为返回值的函数,例如gmtime;另一类是在一系列调用之间要求静态环境的函数,例如strtok。这些函数不改变
接口难以做到线程安全, pthreads定义了现存函数的变体,在相应函数名结尾加后缀_r,这些变体是线程安全的。因此,在使用标准库函数的时候要注意有线程安全版本的一定要用线程安全版本。有里知花
    具体那些函数有线程安全问题,可以参考APUEv2第12章或者Whitepaper: Thread-safety and POSIX.1
Q:errno是线程安全的吗?
A:errno是线程专有数据(参见线程专有数据一节),一个线程一个,互不影响。之所以可以像全局变量一样用,是因为用宏包装了一下。
Q:C标准输入输出流(STDIO)是线程安全的吗?
A: STDIO是线程安全的,所有的函数内部都加了锁。如果你只是想在文件尾追加数据,不关心数据具体被写到哪个位置,那么可以放心的使用fwrite去写。

本文发布于:2023-06-17 18:35:43,感谢您对本站的认可!

本文链接:https://www.wtabcd.cn/fanwen/fan/90/148498.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:线程   操作   使用   开销
相关文章
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2022 Comsenz Inc.Powered by © 专利检索| 网站地图