Nov9

Amazon新版系统购物体验

Author: leeon  Click: 6921   Comments: 0 Category: 生活  Tag: amazon,joyo,卓越亚马逊

最近买了两本书,在订购下单后,就用网银的方式给amazon的系统进行了转账,由于需要另外再订购一本书,故取消了订单,重新订购所有图书后重新下单,再次下单后,整个流程中并没有在意付钱方式,因为amazon的系统中已经有我转账的金额足够支付所有,故并没有留意下单过程中的一些变化。amazon新版的购买流程变得很不适应,只注意了几个以前买书的时候习惯性的几个必填项,并没有注意付款方式的选项改变。这里下单后系统默认的是货到付款,amazon新版系统的白痴地方就在这里,我账户里有足够的金额,再次下单后却没有根据系统内的账户余额扣款,而是选择下单流程中系统默认勾选的“货到付款”。amazon那凌乱视觉极差的界面让人注意力非常不集中,新版真有够垃圾的。

同时,订单界面也没有可以一个路径引导用户使用系统的账户余额进行订单消费,不得不说amazon的账户系统有多垃圾了

Nov9

【转】利用Psyco提升Python运行速度

Author: 51cto  Click: 10976   Comments: 0 Category: python  Tag: python,psyco
Psyco 是严格地在 Python 运行时进行操作的。也就是说,Python 源代码是通过 python 命令编译成字节码的,所用的方式和以前完全相同(除了为调用 Psyco 而添加的几个 import 语句和函数调用)。但是当 Python 解释器运行应用程序时,Psyco 会不时地检查,看是否能用一些专门的机器代码去替换常规的 Python 字节码操作。这种专门的编译和 Java 即时编译器所进行的操作非常类似(一般地说,至少是这样),并且是特定于体系结构的。到现在为止,Psyco 只可用于 i386 CPU 体系结构。Psyco 的妙处在于可以使用您一直在编写的 Python 代码(完全一样!),却可以让它运行得更快。
Psyco 是如何工作的

要完全理解 Psyco,您可能需要很好地掌握 Python 解释器的 eval_frame() 函数和 i386 汇编语言。遗憾的是,我自己不能对其中任何一项发表专家性的意见 - 但是我想我可以大致不差地概述 Psyco。
在常规的 Python 中,eval_frame() 函数是 Python 解释器的内循环。eval_frame() 函数主要察看执行上下文中的当前字节码,并将控制向外切换到一个适合实现该字节码的函数。支持函数将做什么的具体细节通常取决于保存在内存中的各种 Python 对象的状态。简单点说,添加 Python 对象“2”和“3”和添加对象“5”和“6”会产生不同的结果,但是这两个操作都以类似的方式分派。
Psyco 用复合求值单元替代 eval_frame() 函数。Psyco 有几种方法可以用来改进 Python 所进行的操作。首先,Psyco 将操作编译成有点优化的机器码;由于机器码需要完成的工作和 Python 的分派函数所要做的事一样,所以其本身只有些许改进。而且,Psyco 编译中的“专门的”内容不仅仅是对 Python 字节码的选择,Psyco 也要对执行上下文中已知的变量值进行专门化。例如,在类似于下面的代码中,变量 x 在循环持续时间内是可知的:
x = 5
l = []
for i in range(1000):
l.append(x*i)
该段代码的优化版本不需要用“x 变量/对象的内容”乘每个 i,与之相比,简单地用 5 乘以每个 i 所用的开销较少,省略了查找/间接引用这一步。
除为小型操作创建特定于 i386 的代码之外,Psyco 还高速缓存这个已编译的机器码以备今后重用。如果 Psyco 能够识别出特定的操作和早先所执行的(“专门化的”)操作一样,那么,它就能依靠这个高速缓存的代码而不需要再次编译代码段。这样就节省了一些时间。
但是,Psyco 中真正省时的原因在于 Psyco 将操作分成三个不同的级别。对于 Psyco,有“运行时”、“编译时”和“虚拟时”变量。Psyco 根据需要提高和降低变量的级别。运行时变量只是常规 Python 解释器处理的原始字节码和对象结构。一旦 Psyco 将操作编译成机器码,那么编译时变量就会在机器寄存器和可直接访问的内存位置中表示。
最有意思的级别是虚拟时变量。在内部,一个 Python 变量就是一个有许多成员组成的完整结构 - 即使当对象只代表一个整数时也是如此。Psyco 虚拟时变量代表了需要时可能会被构建的 Python 对象,但是这些对象的详细信息在它们成为 Python 对象之前是被忽略的。例如,考虑如下赋值:
x = 15 * (14 + (13 - (12 / 11)))
标准的 Python 会构建和破坏许多对象以计算这个值。构建一个完整的整数对象以保存 (12/11) 这个值;然后从临时对象的结构中“拉”出一个值并用它计算新的临时对象 (13-PyInt)。而 Psyco 跳过这些对象,只计算这些值,因为它知道“如果需要”,可以从值创建一个对象。
使用 Psyco

解释 Psyco 相对比较困难,但是使用 Psyco 就非常容易了。基本上,其全部内容就是告诉 Psyco 模块哪个函数/方法要“专门化”。任何 Python 函数和类本身的代码都不需进行更改。
有几种方法可以指定 Psyco 应该做什么。“猎枪(shotgun)”方法使得随处都可使用 Psyco 即时操作。要做到这点,把下列行置于模块顶端:
import psyco ; psyco.jit()
from psyco.classes import *
第一行告诉 Psyco 对所有全局函数“发挥其魔力”。第二行(在 Python 2.2 及以上版本中)告诉 Psyco 对类方法执行相同的操作。为了更精确地确定 Psyco 的行为,可以使用下列命令:
psyco.bind(somefunc) # or method, class
newname = psyco.proxy(func)
第二种形式把 func 作为标准的 Python 函数,但是优化了涉及 newname 的调用。除了测试和调试之外的几乎所有的情况下,您都将使用 psyco.bind() 形式。

Psyco 的性能

尽管 Psyco 如此神奇,使用它仍然需要一点思考和测试。主要是要明白 Psyco 对于处理多次循环的块是很有用的,而且它知道如何优化涉及整数和浮点数的操作。对于非循环函数和其它类型对象的操作,Psyco 多半只会增加其分析和内部编译的开销。而且,对于含有大量函数和类的应用程序来说,在整个应用程序范围启用 Psyco,会在机器码编译和用于这一高速缓存的内存使用方面增加大量的负担。有选择性地绑定那些可以从 Psyco 的优化中获得最大收益的函数,这样会好得多。
我以十分幼稚的方式开始了我的测试过程。我仅仅考虑了我近来运行的、但还未考虑加速的应用程序。想到的第一个示例是用来将我即将出版的书稿(Text Processing in Python)转换成 LaTeX 格式的文本操作程序。该应用程序使用了一些字符串方法、一些正则表达式和一些主要由正则表达式和字符串匹配所驱动的程序逻辑。实际上将它用作 Psyco 的测试候选是很糟的选择,但是我还是使用了,就这么开始了。
第一遍测试中,我所做的就是将 psyco.jit() 添加到脚本顶端。这做起来一点都不费力。遗憾的是,结果(意料当中)很令人失望。原先脚本运行要花费 8.5 秒,经过 Psyco 的“加速”后它大概要运行 12 秒。真差劲!我猜测大概是即时编译所需的启动开销拖累了运行时间。因此接下来我试着处理一个更大的输入文件(由原来那个输入文件的多个副本组成)。这次获得了小小的成功,将运行时间从 120 秒左右减到了 110 秒。几次运行中的加速效果比较一致,但是效果都不显著。
本处理候选项的第二遍测试中。我只添加了 psyco.bind(main) 这一行,而不是添加一个总的 psyco.jit() 调用,因为 main() 函数确实要循环多次(但是仅利用了最少的整数运算)。这里的结果名义上要比前面好。这种方法将正常的运行时间削减了十分之几秒,在较大的输入版本的情况下削减了数秒钟。但是仍然没有引入瞩目的结果发生(但也没产生什么害处)。

为进行更恰当的 Psyco 测试,我搜寻出我在以前的文章里编写的一些神经网络代码(请参阅“参考资料”)。这个“代码识别器(code_recognizer)”应用程序可以经“训练”用于识别不同编程语言编写的不同 ASCII 值的可能分布情况。类似于这样的东西可能在猜测文件类型方面(比方说丢失的网络信息包)将很有用;但是,关于“训练”些什么,代码实际上完全是通用的 - 它能很容易地学会识别面孔、声音或潮汐模式。任何情况下,“代码识别器”都基于 Python 库 bpnn,Psyco 4.0 分发版也包含(以修正的形式)了该库作为测试用例。在本文中,对“代码识别器”要重点了解它做了许多浮点运算循环并花费了很长的运行时间。这里我们已经有了一个能用于 Psyco 测试的好的候选用例。
使用了一段时间后,我建立了有关 Psyco 用法的一些详细信息。对于这种只有少量类和函数的应用程序,使用即时绑定还是目标绑定没有太大区别。但最佳的结果是,通过有选择性地绑定最优化类,仍可得到几个百分点的改进。然而,更值得注意的是要理解 Psyco 绑定的作用域,这一点很重要。
code_recognizer.py 脚本包括类似于下面的这些行:
从 bpnn 导入 NN
class NN2(NN):
# customized output methods, math core inherited
也就是说,从 Psyco 的观点来看,有趣的事情在类 bpnn.NN 之中。把 psyco.jit() 或 psyco.bind(NN2) 添加到 code_recognizer.py 脚本中起不了什么作用。要使 Psyco 进行期望的优化,需要将 psyco.bind(NN) 添加到 code_recognizer.py 或者将 psyco.jit() 添加到 bpnn.py。与您可能假设的情况相反,即时优化不在创建实例时或方法运行时发生,而是在定义类的作用域内发生。另外,绑定派生类不会专门化其从其它地方继承的方法。
一旦找到适当的 Psyco 绑定的细微的详细信息,那么加速效果是相当明显的。使用参考文章中提供的相同测试用例和训练方法(500 个训练模式,1000 个训练迭代),神经网络训练时间从 2000 秒左右减到了 600 秒左右 - 提速了 3 倍多。将迭代次数降到 10,加速的倍数也成比例降低(但对神经网络的识别能力无效),迭代的中间数值也会如此变化。
我发现使用两行新代码就能将运行时间从超过半小时减到 10 分钟左右,效果非常显著。这种加速仍可能比 C 编写的类似应用程序的速度慢,而且它肯定比几个独立的 Psyco 测试用例所反映出的 100 倍加速要慢。但是这种应用程序是相当“真实的”,而且在许多环境中这些改进已经是够显著的了。

Nov8

如何编写一个动态链接库

Author: leeon  Click: 7046   Comments: 0 Category: c/c++  Tag: 动态链接库

一、编写合格的动态链接库头文件

C语言的头文件,可供一个或多个程序引用,里面一般定义程序所需的常量,自定义类型及函数原型说明等.其中的函数原型说明,则供编译器检查语法,用于排除引用参数时类型不一致的错误.只有编写合格的动态链接库头文件,程序员才能正确使用动态链接库内的函数.

动态链接库头文件要采用C语言标准格式,其中的动态函数原型定义,不必象上文介绍的那样用(*动态函数名)的描述形式.请看下面的例子每行开始的数字为所在行行号,为笔者添加,供注解使用)

[code="cpp"]
#ifndef __DATETIME_H
#define __DATETIME_H
/* 日期结构 */
typedef struct
{
int year;
int mon;
int day;
}DATETYPE;
/* 时间结构 */
typedef struct
{
char hour;
char min;
char sec;
}TIMETYPE;
int getdate(DATETYPE *d); /* 取当前日期 */
int gettime(TIMETYPE *t); /* 取当前时间 */
#endif
[/code] 

注:与上文的datetime.h文件比较,从该头文件第23,24行可以看到,动态函数getdate,gettime的原型定义改变了,不再使用(*getdate),(*gettime)的格式了(这种格式使用较为罗嗦).

二、正确编译与命名动态链接库

为了让GCC编译器生成动态链接库,编译时须加选项-shared.(这点须牢记)

LINUX系统中,为了让动态链接库能被系统中其它程序共享,其名字应符合“lib*.so*”这种格式.如果某个动态链接库不符合此格式,则LINUX的动态链接库自动装入程序(ld.so)将搜索不到此链接库,其它程序也无法共享之.

格式中,第一个*通常表示为简写的库名,第二个*通常表示为该库的版本号.如:在我的系统中,基本C动态链接库的名字为libc.so.6,线程pthread动态链接库的名字为libpthread.so.0等等.本文例子所生成的动态链接库的名字为libmy.so,虽没有版本号,但也符合所要求的格式.

生成该动态链接库的维护文件makefile-lib内容如下:

[code="plain"]
all : libmy.so
SRC = getdate.c gettime.c
TGT = $(SRC:.c=.o)
$(SRC) : adatetime.h
@touch $@
%.o : %.c
cc -c $?
# 动态链接库(libmy.so)生成
libmy.so : $(TGT)
cc -s -shared -o $@ $(TGT)
[/code]

运行命令:

[code="bash"]
$ make -f makefile-lib
$
[/code]

即生成libmy.so库.

注: 维护文件中,第17行用-shared选项以生成动态链接库,用-s选项以去掉目标文件中的符号表,从而减小文件长度.

三、共享动态链接库

3.1 动态链接库配置文件

为了让动态链接库为系统所使用,需要维护动态链接库的配置文件--/etc/ld.so.conf.此文件内,存放着可被LINUX共享的动态链接库所在目录的名字(系统目录/lib,/usr/lib除外),各个目录名间以空白字符(空格,换行等)或冒号或逗号分隔.一般的LINUX发行版中,此文件均含一个共享目录/usr/X11R6/lib,为X window窗口系统的动态链接库所在的目录.

下面看看我的系统中此文件的内容如何:

[code="bash"]
# cat /etc/ld.so.conf
/usr/X11R6/lib
/usr/zzz/lib
#
[/code]

由上可以看出,该动态库配置文件中,增加了一个/usr/zzz/lib目录.这是我自己新建的共享库目录,下面存放我新开发的可供系统共享的动态链接库.

3.2 动态链接库管理命令

为了让动态链接库为系统所共享,还需运行动态链接库的管理命令--ldconfig.此执行程序存放在/sbin目录下.

ldconfig命令的用途,主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下,搜索出可共享的动态链接库(格式如前介绍,lib*.so*),进而创建出动态装入程序(ld.so)所需的连接和缓存文件.缓存文件默认为/etc/ld.so.cache,此文件保存已排好序的动态链接库名字列表.

ldconfig通常在系统启动时运行,而当用户安装了一个新的动态链接库时,就需要手工运行这个命令.

ldconfig命令行用法如下:

ldconfig [-v|--verbose] [-n] [-N] [-X] [-f CONF] [-C CACHE] [-r ROOT] [-l] [-p|--print-cache] [-c FORMAT] [--format=FORMAT] [-V] [-?|--help|--usage] path...

ldconfig可用的选项说明如下:

(1) -v或--verbose : 用此选项时,ldconfig将显示正在扫描的目录及搜索到的动态链接库,还有它所创建的连接的名字.

(2) -n : 用此选项时,ldconfig仅扫描命令行指定的目录,不扫描默认目录(/lib,/usr/lib),也不扫描配置文件/etc/ld.so.conf所列的目录.

(3) -N : 此选项指示ldconfig不重建缓存文件(/etc/ld.so.cache).若未用-X选项,ldconfig照常更新文件的连接.

(4) -X : 此选项指示ldconfig不更新文件的连接.若未用-N选项,则缓存文件正常更新.

(5) -f CONF : 此选项指定动态链接库的配置文件为CONF,系统默认为/etc/ld.so.conf.

(6) -C CACHE : 此选项指定生成的缓存文件为CACHE,系统默认的是/etc/ld.so.cache,此文件存放已排好序的可共享的动态链接库的列表.

(7) -r ROOT : 此选项改变应用程序的根目录为ROOT(是调用chroot函数实现的).选择此项时,系统默认的配置文件/etc/ld.so.conf,实际对应的为ROOT/etc/ld.so.conf.如用-r /usr/zzz时,打开配置文件/etc/ld.so.conf时,实际打开的是/usr/zzz/etc/ld.so.conf文件.用此选项,可以大大增加动态链接库管理的灵活性.

( -l : 通常情况下,ldconfig搜索动态链接库时将自动建立动态链接库的连接.选择此项时,将进入专家模式,需要手工设置连接.一般用户不用此项.

(9) -p或--print-cache : 此选项指示ldconfig打印出当前缓存文件所保存的所有共享库的名字.

(10) -c FORMAT 或 --format=FORMAT : 此选项用于指定缓存文件所使用的格式,共有三种ld(老格式),new(新格式)和compat(兼容格式,此为默认格式).

(11) -V : 此选项打印出ldconfig的版本信息,而后退出.

(12) -? 或 --help 或 --usage : 这三个选项作用相同,都是让ldconfig打印出其帮助信息,而后退出.

举三个例子:

例1:

[code="bash"]
# ldconfig -p
793 libs found in cache `/etc/ld.so.cache'
libzvt.so.2 (libc6) => /usr/lib/libzvt.so.2
libzvt.so (libc6) => /usr/lib/libzvt.so
libz.so.1.1.3 (libc6) => /usr/lib/libz.so.1.1.3
libz.so.1 (libc6) => /lib/libz.so.1
......
#
[/code]

注: 有时候用户想知道系统中有哪些动态链接库,或者想知道系统中有没有某个动态链接库,这时,可用-p选项让ldconfig输出缓存文件中的动态链接库列表,从而查询得到.例子中,ldconfig命令的输出结果第1行表明在缓存文件/etc/ld.so.cache中找到793个共享库,第2行开始便是一系列共享库的名字及其全名(绝对路径).因为实际输出结果太多,为节省篇幅,以......表示省略的部分.

例2:

[code="bash"]# ldconfig -v
/lib:
liby.so.1 -> liby.so.1
libnss_wins.so -> libnss_wins.so
......
/usr/lib:
libjscript.so.2 -> libjscript.so.2.0.0
libkspell.so.2 -> libkspell.so.2.0.0
......
/usr/X11R6/lib:
libmej-0.8.10.so -> libmej-0.8.10.so
libXaw3d.so.7 -> libXaw3d.so.7.0
......
# [/code]

注: ldconfig命令在运行正常的情况下,默认不输出什么东西.本例中用了-v选项,以使ldconfig在运行时输出正在扫描的目录及搜索到的共享库,用户可以清楚地看到运行的结果.执行结束后,ldconfig将刷新缓存文件/etc/ld.so.cache.

例3:

[code="bash"]# ldconfig /usr/zhsoft/lib
# [/code]

注: 当用户在某个目录下面创建或拷贝了一个动态链接库,若想使其被系统共享,可以执行一下"ldconfig 目录名"这个命令.此命令的功能在于让ldconfig将指定目录下的动态链接库被系统共享起来,意即:在缓存文件/etc/ld.so.cache中追加进指定目录下的共享库.本例让系统共享了/usr/zhsoft/lib目录下的动态链接库.需要说明的是,如果此目录不在/lib,/usr/lib及/etc/ld.so.conf文件所列的目录里面,则再度运行ldconfig时,此目录下的动态链接库可能不被系统共享了.

3.3 动态链接库如何共享

了解了以上知识,我们可以采用以下三种方法来共享动态链接库注:均须在超级用户状态下操作,以我的动态链接库libmy.so共享过程为例)

(1)拷贝动态链接库到系统共享目录下,或在系统共享目录下为该动态链接库建立个连接(硬连接或符号连接均可,常用符号连接).这里说的系统共享目录,指的是LINUX动态链接库存放的目录,它包含/lib,/usr/lib以及/etc/ld.so.conf文件内所列的一系列目录.

[code="bash"]# cp libmy.so /lib
# ldconfig
# [/code]

或:

[code="bash"]# ln -s `pwd`/libmy.so /lib
# ldconfig
# [/code]

(2)将动态链接库所在目录名追加到动态链接库配置文件/etc/ld.so.conf中.

[code="bash"]# pwd >> /etc/ld.so.conf
# ldconfig
# [/code]

(3)利用动态链接库管理命令ldconfig,强制其搜索指定目录,并更新缓存文件,便于动态装入.

[code="bash"]# ldconfig `pwd`
# [/code]

需要说明的是,这种操作方法虽然有效,但效果是暂时的,供程序测试还可以,一旦再度运行ldconfig,则缓存文件内容可能改变,所需的动态链接库可能不被系统共享了.与之相比较,前两种方法是可靠的方法,值得业已定型的动态链接库共享时采用.前两种方法还有一个特点,即最后一条命令都是ldconfig,也即均需要更新一下缓存文件,以确保动态链接库的共享生效.

四、含有动态函数的程序的编译

4.1 防止编译因未指定动态链接库而出错

当一个程序使用动态函数时,编译该程序时就必须指定含所用动态函数的动态链接库,否则编译将会出错退出.如本文示例程序ady.c的编译(未明确引用动态链接库libmy.so):

[code="bash"]# cc -o ady ady.c
/tmp/ccL4FsJp.o: In function `main':
/tmp/ccL4FsJp.o(.text+0x43): undefined reference to `gettime'
collect2: ld returned 1 exit status
# [/code]

注: 因为ady.c所含的动态函数getdate,gettime不在系统函数库中,所以连接时出错.

4.2 编译时引用动态链接库的几种方式

(1)当所用的动态链接库在系统目录(/lib,/usr/lib)下时,可用编译选项-l来引用.即:

[code="bash"]# cc -lmy -o ady ady.c
# [/code]

注:编译时用-l选项引用动态链接库时,库名须使用其缩写形式.本例的my,表示引用libmy.so库.若引用光标库libncurses.so,须用-lncurses.注意,-l选项与参数之间不能有空格,否则会出错.

(2)当所用的动态链接库在系统目录(/lib,/usr/lib)以外的目录时,须用编译选项-L来指定动态链接库所在的目录(供编译器查找用),同时用-l选项指定缩写的动态链接库名.即:

[code="bash"]# cc -L/usr/zzz/lib -lmy -o ady ady.c
# [/code]

(3)直接引用所需的动态链接库.即:

[code="bash"]
# cc -o ady ady.c libmy.so
# [/code]

[code="bash"]
# cc -o ady ady.c /lib/libmy.so
#[/code] 

等等.其中,动态链接库的库名可以采用相对路径形式(文件名不以/开头),也可采用绝对路径形式(文件名以/开头).

五、动态链接程序的运行与检查

5.1 运行

编译连接好含动态函数的程序后,就可以运行它了.动态链接程序因为共享了系统中的动态链接库,所以其空间占用很小.但这并不意味功能的减少,它的执行与静态连接的程序执行,效果完全相同.在命令提示符下键入程序名及相关参数后回车即可,如下例:

$ ady
动态链接库高级应用示范
当前日期: 2002-03-11
当前时间: 19:39:06
$

5.2 检查

检查什么?检查动态链接程序究竟需要哪些共享库,系统中是否已有这些库,没有的话,用户好想办法把这些库装上.

怎么检查呢?这里,告诉你一个实用程序--ldd,这个程序就是专门用来检查动态链接程序依赖哪些共享库的.

ldd命令行用法如下:

ldd [--version] [-v|--verbose] [-d|--data-relocs] [-r|--function-relocs] [--help] FILE...

各选项说明如下:

(1) --version : 此选项用于打印出ldd的版本号.

(2) -v 或 --verbose : 此选项指示ldd输出关于所依赖的动态链接库的尽可能详细的信息.

(3) -d 或 --data-relocs : 此选项执行重定位,并且显示不存在的函数.

(4) -r 或 --function-relocs : 此选项执行数据对象与函数的重定位,同时报告不存在的对象.

(5) --help : 此选项用于打印出ldd的帮助信息.

注: 上述选项中,常用-v(或--verbose)选项.

ldd的命令行参数为FILE...,即一个或多个文件名(动态链接程序或动态链接库).

例1:

[code="bash"]$ ldd ady
libmy.so => ./libmy.so (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40028000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ [/code]

注: 每行=>前面的,为动态链接程序所需的动态链接库的名字,而=>后面的,则是运行时系统实际调用的动态链接库的名字,所需的动态链接库在系统中不存在时,=>后面将显示"not found",括号所括的数字为虚拟的执行地址.本例列出ady所需的三个动态链接库,其中libmy.so为自己新建的动态链接库,而libc.so.6与/lib/ld-linux.so.2均为系统的动态链接库,前一个为基本C库,后一个动态装入库(用于动态链接库的装入及运行).

例2:

[code="bash"] $ ldd -v ady
libmy.so => ./libmy.so (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40028000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Version information:
./ady:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
./libmy.so:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
$ [/code]

注:本例用-v选项以显示尽可能多的信息,所以例中除列出ady所需要的动态链接库外,还列出了程序所需动态链接库版本方面的信息.

小结: 在LINUX动态链接库的高级应用中,关键有两点,一是如何让动态链接库为LINUX系统所共享,二是编译连接程序时如何做.让动态链接库为系统所共享,主要是用ldconfig管理命令,维护好系统共享库的缓存文件/etc/ld.so.cache.编译连接时如何做?注意连接上所用的动态链接库就可以了.LINUX动态链接库的高级应用,用一用就明白:其实,就是这么简单!

Oct31

MySQL锁机制/管理(并发锁,行锁,表锁,预加锁,全局锁等等)

Author: mysqlab.net  Click: 8216   Comments: 0 Category: 数据库  Tag: mysql

1. MySQL中并发和隔离控制机制

  • Meta-data元数据锁:在table cache缓存里实现的,为DDL(Data Definition Language)提供隔离操作。一种特别的meta-data元数据类型,叫Name Lock。(SQL层)
  • 表级table-level数据锁(SQL层)
  • 存储引擎特有机制 — row locks行锁,page locks页锁,table locks表级,版本控制(在引擎中实现)
  • 全局读锁 — FLUSH TABLES WITH READ LOCK(SQL层)

2.在语句执行中表的生命周期

DML(Data Manipulation Language):

  • 计算语句使用到的所有表
  • 在每个表:打开open表 — 从table cache缓存里得到TABLE对象,并在此表加上meta-data元数据锁
  • 等待全局读锁后改变数据
  • 在每个表:锁lock表 — 在表加上table-level数据锁
  • 执行语句:调用:handler::write_row()/read_rnd()/read_index(),等;隐式地调用引擎级engine-level锁机制
  • 在每个表:释放表的数据锁
  • 在每个表:释放表的DDL锁并把表放回table cache缓存里
  • DDL语句也是一样,没有典型的执行计划。

3.获取meta-data元数据锁

  • meta-data元数据锁的实现作为TABLE对象的一个属性,TABLE对象代表了table cache缓存。
  • meta-data元数据锁为如下任何一种:
    • shared共享锁 — 隐式地加锁,只通过标记TABLE对象“被使用”;
    • semi-exclusive半独享锁,也叫Name Lock,RENAME操作会在源表和目标加上此锁;
    • exclusive独享,也叫exclusive name lock,CREATE TABLE … SELECT操作会在目标表上加上此锁,如果没有的话。

4.表缓存(table cache)

  • 是一个HASH变量,叫open_cache
  • TABLE对象是HASH元素
  • 以HASH的操作被LOCK_open mutex互斥量保护

4.1内部结构(The table cache: internal structure)

  • 在缓存里,每个物理表可能被多个TABLE实例表示
  • 相同表的所有TABLE实例,通过相连的列(a linked list)连接着
  • 每个TABLE实例有一个table cache缓存版本的复制 — TABLE实例保存的版本不会和当前table cache缓存版本一致,而是保存旧的和从缓存删除的
  • 被某些语句使用的TABLE实例被会标记为对其它的语句来说是无效的 — 这就是meta-data元数据锁的本质
  • 在缓存中的TABLE实例通常地有一个有效的句柄实例连接着它

4.2内部运算(The table cache: operations)

  • 主要的代码在:sql/sql_base.cc,sql/lock.cc,sql/table.h,sql/sql_table.cc
  • 主要的方法:open_table(),close_thread_tables(),close_cached_table(),lock_table_names()
  • 事实上,一个概念/对象组合不仅用于缓存或锁定:LOCK_open mutex互斥量也用到其它的操作,如:使磁盘上和处理中的表创建的原子性
  • 典型的操作,来自隔离等级Pov的重要(注:isolation PoV没研究出是什么意思):语句查询时,打开和关闭表 — shared共享锁;强制和等待直到表的所有实例被关闭 —  exclusive独享(但不完全);Name Lock — 特殊地情况,当手上没有TABLE实例,只能使用一个特殊的占位符(甚至表可能不存在)。

4.4锁多表(The table cache: locking multiple tables)

  • 使用一种尝试和回退(try and back-off)的技术来避免死锁(乐观锁)
  • 为了DDL操作的一套诀窍,如使锁升级或者防止DDL失效
  • LOCK_open问题
  • Lock_open互斥量:
  • 保护table cache缓存内的结构
  • 分组存储引擎内的表和对象的.frm文件的创建,也为RENAME操作提供原子性操作
  • 在每个语句访问表时会使用它两次:在open_tables()和close_thread_tables()
  • 在使用DDL操作时,磁盘读写和甚至同步(sync)都会使用它

5.ALTER TABLE例子

ALTER TABLE执行的简化计划:

  • 以TL_WRITE_ALLOW_READ的打开和加锁表(新版 InnoDB Plugin已改为:TL-READ-NO-INSERT)
  • 创建一个以临时名字的被ALTER的复制表
  • 强制并等待直到表的所有实例都关闭(锁升级)
  • 交换新和旧的版本
  • 删除旧的版本

这是一般情况,当然还有优化的情况。

A debug trace for ALTER TABLE

  1. T@8: | query: alter table t1 add column k int
  2. T@8: | >mysql_parse
  3. T@8: | | >mysql_execute_command
  4. T@8: | | | >mysql_alter_table
  5. T@8: | | | | >open_ltable
  6. T@8: | | | | | >open_table
  7. T@8: | | | | | <open_table
  8. T@8: | | | | | >mysql_lock_tables
  9. T@8: | | | | | | >get_lock_data
  10. T@8: | | | | | | | >ha_innobase::store_lock
  11. T@8: | | | | | | | <ha_innobase::store_lock
  12. T@8: | | | | | | <get_lock_data
  13. T@8: | | | | | | >lock_external
  14. T@8: | | | | | | | >ha_innobase::external_lock
  15. T@8: | | | | | | | | enter: lock_type: 1
  16. T@8: | | | | | | | | >trans_register_ha
  17. T@8: | | | | | | | | | enter: stmt
  18. T@8: | | | | | | | | <trans_register_ha
  19. T@8: | | | | | | | <ha_innobase::external_lock
  20. T@8: | | | | | | <lock_external
  21. T@8: | | | | | | >thr_multi_lock
  22. T@8: | | | | | | | >thr_lock
  23. T@8: | | | | | | | <thr_lock
  24. T@8: | | | | | | <thr_multi_lock
  25. T@8: | | | | | <mysql_lock_tables
  26. T@8: | | | | <open_ltable
  27. T@8: | | | | >mysql_create_table
  28. T@8: | | | | <mysql_create_table
  29. T@8: | | | | >open_temporary_table
  30. T@8: | | | | | >openfrm
  31. T@8: | | | | | | >handler::ha_open
  32. T@8: | | | | | | | enter: name: ./test/#sql-3081_1 db_type: 12 db_stat: 7 mode: 2 lock_test: 2
  33. T@8: | | | | | | | >ha_innobase::open
  34. T@8: | | | | | | | <ha_innobase::open
  35. T@8: | | | | | | <handler::ha_open
  36. T@8: | | | | | <openfrm
  37. T@8: | | | | <open_temporary_table
  38. T@8: | | | | >copy_data_between_tables
  39. T@8: | | | | <copy_data_between_tables
  40. T@8: | | | | >closefrm
  41. T@8: | | | | <closefrm
  42. T@8: | | | | >close_cached_table
  43. T@8: | | | | | enter: table: t1
  44. T@8: | | | | | >wait_while_table_is_used
  45. T@8: | | | | | | >get_lock_data
  46. T@8: | | | | | | <get_lock_data
  47. T@8: | | | | | | >thr_abort_locks
  48. T@8: | | | | | | <thr_abort_locks
  49. T@8: | | | | | | >remove_table_from_cache
  50. T@8: | | | | | | | enter: Table: ‘test.t1′ flags: 2
  51. T@8: | | | | | | <remove_table_from_cache
  52. T@8: | | | | | <wait_while_table_is_used
  53. T@8: | | | | | >mysql_unlock_tables
  54. T@8: | | | | | | >thr_multi_unlock
  55. T@8: | | | | | | | lock: data: 0x8b7f9b0 count: 1
  56. T@8: | | | | | | | >thr_unlock
  57. T@8: | | | | | | | <thr_unlock
  58. T@8: | | | | | | <thr_multi_unlock
  59. T@8: | | | | | | >unlock_external
  60. T@8: | | | | | | | >ha_innobase::external_lock
  61. T@8: | | | | | | | <ha_innobase::external_lock
  62. T@8: | | | | | | <unlock_external
  63. T@8: | | | | | <mysql_unlock_tables
  64. T@8: | | | | | >unlink_open_table
  65. T@8: | | | | | | >hash_delete
  66. T@8: | | | | | | | >free_cache_entry
  67. T@8: | | | | | | | | >closefrm
  68. T@8: | | | | | | | | | >ha_innobase::close
  69. T@8: | | | | | | | | | <ha_innobase::close
  70. T@8: | | | | | | | | <closefrm
  71. T@8: | | | | | | | <free_cache_entry
  72. T@8: | | | | | | <hash_delete
  73. T@8: | | | | | <unlink_open_table
  74. T@8: | | | | <close_cached_table
  75. T@8: | | | | >mysql_rename_table
  76. T@8: | | | | | >ha_innobase::rename_table
  77. T@8: | | | | | <ha_innobase::rename_table
  78. T@8: | | | | <mysql_rename_table
  79. T@8: | | | | >mysql_rename_table
  80. T@8: | | | | | >ha_innobase::rename_table
  81. T@8: | | | | | <ha_innobase::rename_table
  82. T@8: | | | | <mysql_rename_table
  83. T@8: | | | | >my_delete
  84. T@8: | | | | | my: name ./test/#sql2-3081-1.frm MyFlags 0
  85. T@8: | | | | <my_delete
  86. T@8: | | | | >ha_delete_table
  87. T@8: | | | | | >ha_innobase::delete_table
  88. T@8: | | | | | <ha_innobase::delete_table
  89. T@8: | | | | <ha_delete_table
  90. T@8: | | | | >ha_commit_trans T@8: | | | | <ha_commit_trans T@8: | | | | >ha_commit_trans T@8: | | | | <ha_commit_trans T@8: | | | <mysql_alter_table
  91. T@8: | | <mysql_execute_command
  92. T@8: | <mysql_parse
  93. T@8: <dispatch_command

6.RENAME TABLE例子

  • 得到源表和目的表的name-lock锁:在table cache缓存内插入特殊的TABLE实例的占位符并等待直到这些表的所有实例都关闭
  • 重命名这些表的.frm文件和调用handler::rename_table()方法
  • 删除name-lock锁

在整个解析过程中,都使用LOCK_open

Simplified debug trace for RENAME TABLE

  1. T@10: | query: rename table t1 to t2
  2. T@10: | >mysql_parse
  3. T@10: | | >mysql_execute_command
  4. T@10: | | | >mysql_rename_tables
  5. T@10: | | | | >lock_table_names
  6. T@10: | | | | | >lock_table_name
  7. T@10: | | | | | | enter: db: test name: t1
  8. T@10: | | | | | <lock_table_name
  9. T@10: | | | | | >remove_table_from_cache
  10. T@10: | | | | | | enter: Table: ‘test.t1′ flags: 0
  11. T@10: | | | | | | >hash_delete
  12. T@10: | | | | | | | >free_cache_entry
  13. T@10: | | | | | | | | >closefrm
  14. T@10: | | | | | | | | | >ha_innobase::close
  15. T@10: | | | | | | | | | <ha_innobase::close
  16. T@10: | | | | | | | | <closefrm
  17. T@10: | | | | | | | <free_cache_entry
  18. T@10: | | | | | | <hash_delete
  19. T@10: | | | | | <remove_table_from_cache
  20. T@10: | | | | | >lock_table_name
  21. T@10: | | | | | | enter: db: test name: t2
  22. T@10: | | | | | <lock_table_name
  23. T@10: | | | | | >remove_table_from_cache
  24. T@10: | | | | | | enter: Table: ‘test.t2′ flags: 0
  25. T@10: | | | | | <remove_table_from_cache
  26. T@10: | | | | <lock_table_names
  27. T@10: | | | | >rename_tables
  28. T@10: | | | | | >do_rename
  29. T@10: | | | | | | >mysql_rename_table
  30. T@10: | | | | | | | >ha_innobase::rename_table
  31. T@10: | | | | | | | <ha_innobase::rename_table
  32. T@10: | | | | | | | >my_rename
  33. T@10: | | | | | | | | my: from ./test/t1.frm to ./test/t2.frm MyFlags 16
  34. T@10: | | | | | | | <my_rename
  35. T@10: | | | | | | <mysql_rename_table
  36. T@10: | | | | | <do_rename
  37. T@10: | | | | <rename_tables
  38. T@10: | | | | >unlock_table_names
  39. T@10: | | | | | >unlock_table_name
  40. T@10: | | | | | | >hash_delete
  41. T@10: | | | | | | | >free_cache_entry
  42. T@10: | | | | | | | <free_cache_entry
  43. T@10: | | | | | | <hash_delete
  44. T@10: | | | | | <unlock_table_name
  45. T@10: | | | | | >unlock_table_name
  46. T@10: | | | | | | >hash_delete
  47. T@10: | | | | | | | >free_cache_entry
  48. T@10: | | | | | | | <free_cache_entry
  49. T@10: | | | | | | <hash_delete
  50. T@10: | | | | | <unlock_table_name
  51. T@10: | | | | <unlock_table_names
  52. T@10: | | | <mysql_rename_tables
  53. T@10: | | <mysql_execute_command
  54. T@10: | <mysql_parse

7.表级table-level锁

  • 主要源代码见:sql/lock.cc,mysys/thr_lock.cc。mysql_lock/unlock_tables()(SQL层操作)和thr_multi_lock()/thr_lock()(锁兼容逻辑lock-compatibility logic)
  • 表是以打开着被加锁的。被加锁的对象被句柄关联着;存储引擎会调整锁的类型。如innodb/bdb,事实上大量的对象被加锁的,如merge/partition,见handler::store_lock()方法。
  • 使用锁等级避免死锁。所有表一次性加锁;如果存储引擎调整锁造成死锁,由存储引擎负责
  • 在一些情况下,表会更早地被解锁

8 .预加锁(pre-locking)

  • 历史上避免死锁方案用于表级table-level数据锁,是要求一次性加锁一个语句内的所有表
  • 因此,对语句使用的函数/触发,我们不得不打开所有直接地或间接地用到的表,且对它们加锁。为这个,我们建立一个被使用表的可传送闭包
  • 为了有效实现,我们混合层次和访问(layers and access)成某些解析/语句上下文(parser/statement context),这些上下文来自主要处理表的模板

9.全局读锁(global read lock)

  • 实现为FLUSH TABLES WITH READ LOCK,用来备份
  • 从执行上防止DDL和DML
  • 建议:每个DDL/DML语句检查是否有一个正挂着的全局读锁和停止是否有任何一个。
    • 通过直接调用wait_if_global_read_lock()(在这个情况我们会设置来自全局读锁的保护,且只有调用start_waiting_global_read_lock()来消除这个保护,通常在这情况下没有打开的表);
    • 或者通过mysql_lock_tables()(在后一种情况下,我们还重新打开表)
  • 线程操作FLUSH TABLES WITH READ LOCK来设置一个全局读锁的标识,初始一个FLUSH TABLES语句,然后等待直到所有的表缓存都清空

分类

标签

归档

最新评论

Abyss在00:04:28评论了
Linux中ramdisk,tmpfs,ramfs的介绍与性能测试
shallwe99在10:21:17评论了
【原创】如何在微信小程序开发中正确的使用vant ui组件
默一在09:04:53评论了
Berkeley DB 由浅入深【转自架构师杨建】
Memory在14:09:22评论了
【原创】最佳PHP框架选择(phalcon,yaf,laravel,thinkphp,yii)
leo在17:57:04评论了
shell中使用while循环ssh的注意事项

我看过的书

链接

其他

访问本站种子 本站平均热度:9360 c° 本站链接数:1 个 本站标签数:464 个 本站被评论次数:94 次