Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1124674
  • 博文数量: 177
  • 博客积分: 761
  • 博客等级: 上士
  • 技术积分: 1518
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-04 22:37
文章分类

全部博文(177)

文章存档

2017年(1)

2016年(3)

2015年(33)

2014年(48)

2013年(60)

2012年(32)

分类:

2015-01-28 23:28:04

原文地址:关于NPTL和TLS库 作者:osama123

关于NPTL和TLS库
   
    这里摘抄了一篇文章,大体是讲述NPTL(Native Posix Thread Library)库的,这是一个新的线程库,在内核针对NPTL做出一定修改后,如果使用这个库,号称能够在2秒钟生成2000个线程,而使用old linuxthreads库的版本的linux需要15minutes!这个测试据说是Wikpedia作的。NPTL库针对需要建立很多线程的服务器应用来说是个福音,但对于普通的应用来说,与linuxthreads差别不大。NPTL库一般位于/lib/tls目录下,使用TLS是个misleading的主意,因为tls是Thread Local Storage的意思,在old linuxthreads库里,早就支持tls了。
    这篇文章里还讲述了就算我们的系统里装上了NPTL库,也不会影响原来的程序,就算是那些老的程序,即使用了linuxthreads的头文件且在编译,连接的时候使用了linuxthreads的库的程序,我们也能够让它在执行的时候,动态连接到我们的NPTL库。从而发挥NPTL的作用。如果有些老的程序不能在我们的NPTL上正常的运行,需要运行老的linuxthreads库的话,只需要定义变量:
      
         LD_ASSUME_KERNEL=2.4.30
	即假设我们运行的内核的版本是这样的一个老版本。举例如下:当前我们的
系统中已经使用了NPTL.
volkerdi@tree:~$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7fcb000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7eaf000)
/lib/ld-linux.so.2 (0xb7feb000)

Note that in the example above, the binary is running against the NPTL
libraries in /lib/tls. Now, let's try setting LD_ASSUME_KERNEL:

volkerdi@tree:~$ LD_ASSUME_KERNEL=2.4.30 ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fcb000)
libc.so.6 => /lib/libc.so.6 (0xb7eb2000)
/lib/ld-linux.so.2 (0xb7feb000)


    下面是转载文章的全文:
连接:


This version of Slackware contains support in glibc for NPTL (the Native 
POSIX Thread Library). NPTL works with newer kernels (meaning 2.6.x, or
a 2.4 kernel that is patched to support NPTL, but not an unmodified
"vanilla" 2.4 kernel such as Slackware uses) to provide improved
performance for threads. This difference can be quite dramatic in some
situations. For example, a benchmark test mentioned on Wikipedia
started 100,000 threads simultaneously in about 2 seconds on a system
using NPTL. The same test using the old Linuxthreads glibc thread
support took around 15 minutes to run! For most applications that do
not start large numbers of threads the difference here will not be so
large, but for high traffic servers, databases, or anything that runs
large numbers of threads, NPTL should bring big improvements in
scalability and performance. For compatibility, the regular
(linuxthreads) libraries are installed in /lib, and the new NPTL
versions are installed in /lib/tls. Which versions are used depends on
the kernel you're using. If it's newer than 2.6.4, then the NPTL
libraries in /lib/tls will be used. TLS stands for "thread-local
storage", and the directory name /lib/tls is a little bit misleading
since now both the linuxthreads and NPTL versions of glibc are compiled
with TLS support included (this is needed to produce versions of tools
such as ldconfig that can run under either kind of system).

Getting all the kinks out of the build script to be able to get this to
work with either 2.4 or 2.6 kernels and be able to switch back and forth
without issues was quite a challenge, to say the least, and would have
been much harder without all the good advice and help folks sent in to
help me along and give me important hints. A special thanks goes to
Chad Corkrum for sending in some ./configure options that really helped
get the ball rolling here.

Here's some information about compiling things using these libraries --
by default, if you compile something the headers and shared libraries
used to compile and link the binary will be the linuxthreads versions,
but when you go to run the binary it will link to the NPTL library
versions (and you'll get the NPTL speed improvements) if you are running
an NPTL capable kernel. In rare cases you may find that an old binary
doesn't work right when run against the NPTL libs, and in this case you
can force it to run against the linuxthreads versions by setting the
LD_ASSUME_KERNEL variable to assume the use of a 2.4.x (non-NPTL) kernel
so that NPTL will not be used. An easy way to see the effect of this is
to try something like the following while using an NPTL enabled kernel:

volkerdi@tree:~$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7fcb000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7eaf000)
/lib/ld-linux.so.2 (0xb7feb000)

Note that in the example above, the binary is running against the NPTL
libraries in /lib/tls. Now, let's try setting LD_ASSUME_KERNEL:

volkerdi@tree:~$ LD_ASSUME_KERNEL=2.4.30 ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb7fcf000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fcb000)
libc.so.6 => /lib/libc.so.6 (0xb7eb2000)
/lib/ld-linux.so.2 (0xb7feb000)

As you can see, now the binary is running against the linuxthreads
version of glibc in /lib. If you find old things that won't work with
NPTL (which should be rare), this is the method you'll want to use to
work around it.

Now for a little note about compiling things. In most cases it will be
just fine to compile against linuxthreads and run against NPTL, and this
approach will produce the most flexible binaries (ones that will run
against either linuxthreads or NPTL.) However, in some cases you might
want to use some of the new functions that are only available in NPTL,
and to do that you'll need to use the NPTL versions of pthread.h and
other headers that are different and link against the NPTL versions of
the glibc libraries. To do this you'll need to add these compile flags
to your build in an appropriate spot:

-I/usr/include/nptl -L/usr/lib/nptl
(and link with -lpthread, of course)

Have fun, and report any problems to volkerdi@slackware.com.

Pat

阅读(1302) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~