线程共享的环境包括：进程代码段、进程的公有数据(利用这些共享的数据，线程很容易的实现相互之间的通讯)、进程打开的文件描述符、信号的处理器、进程的当前目录和进程用户ID与进程组ID。
&&& 进程拥有这许多共性的同时，还拥有自己的个性。有了这些个性，线程才能实现并发性。这些个性包括：
&&& 1.线程ID&&&&& 每个线程都有自己的线程ID，这个ID在本进程中是唯一的。进程用此来标
&& 识线程。
&&& 2.寄存器组的值&&&&&& 由于线程间是并发运行的，每个线程有自己不同的运行线索，当从一个线
&& 程切换到另一个线程上时，必须将原有的线程的寄存器集合的状态保存，以便
&& 将来该线程在被重新切换到时能得以恢复。
&&& 3.线程的堆栈&&&&&& 堆栈是保证线程独立运行所必须的。&&&&&& 线程函数可以调用函数，而被调用函数中又是可以层层嵌套的，所以线程
&& 必须拥有自己的函数堆栈，使得函数调用可以正常执行，不受其他线程的影
&&& 4.错误返回码&&&&&& 由于同一个进程中有很多个线程在同时运行，可能某个线程进行系统调用
&& 后设置了errno值，而在该线程还没有处理这个错误，另外一个线程就在此时
&& 被调度器投入运行，这样错误值就有可能被修改。&&&&&& 所以，不同的线程应该拥有自己的错误返回码变量。
&&& 5.线程的信号屏蔽码&&&&&& 由于每个线程所感兴趣的信号不同，所以线程的信号屏蔽码应该由线程自己管理。但所有的线程都共享同样的信号处理器。
&&& 6.线程的优先级&&&&&& 由于线程需要像进程那样能够被调度，那么就必须要有可供调度使用的参数，这个参数就是线程的优先级。
& & & 涉及多线程程序涉及的时候经常会出现一些令人难以思议的事情，用堆和栈分配一个变量可能在以后的执行中产生意想不到的结果，而这个结果的表现就是内存的非法被访问，导致内存的内容被更改。&　　理解这个现象的两个基本概念是：在一个进程的线程共享堆区，而进程中的线程各自维持自己堆栈。&
　　在 windows 等平台上，不同线程缺省使用同一个堆，所以用 C 的 malloc （或者 windows 的 GlobalAlloc）分配内存的时候是使用了同步保护的。如果没有同步保护，在两个线程同时执行内存操作的时候会产生竞争条件，可能导致堆内内存管理混乱。比如两个线程分配了统一块内存地址，空闲链表指针错误等。&　　Symbian 的线程一般使用独立的堆空间。这样每个线程可以直接在自己的堆里分配和释放，可以减少同步所引入的开销。当线程退出的时候，系统直接回收线程的堆空间，线程内没有释放的内存空间也不会造成进程内的内存泄漏。&　　但是两个线程使用共用堆的时候，就必须用 critical section 或者 mutex 进行同步保护。否则程序崩溃时早晚的事。如果你的线程需要在共用堆上无规则的分配和释放任何数量和类型的对象，可以定制一个自己的 allcator，在 allocator 内部使用同步保护。线程直接使用这个 allocator 分配内存就可以了。这相当于实现自己的 malloc，free。但是更建议你重新审查一下自己的系统，因为这种情况大多数是不必要的。经过良好的设计，线程的本地堆应该能够满足大多数对象的需求。如果有某一类对象需要在共享堆上创建和共享，这种需求是比较合理的，可以在这个类的 new 和 delete 上实现共享保护。&
阅读(...) 评论()博客访问： 1263621
博文数量： 266
博客积分： 1305
博客等级： 军士长
技术积分： 4603
注册时间：
不懂的东西还有很多，随着不断的学习，不懂的东西更多，无法消灭更多不懂的东西，那就不断的充实自己吧。
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
原文地址： 作者：
讨论关于并发环境下，多个进程对同一文件写入的问题，我们会涉及到文件共享的知识。在开始之前，我们先讨论一些有关文件共享的知识。
1. 文件共享
& Unix系统支持在不同进程间共享打开的文件。为此，我们先介绍一下内核用于所有I/O的数据结构。注意，下面的说明是概念性的，与特定的实现可能匹配，也可能不匹配。
& 内核使用三种数据结构表示打开的文件，它们之间的关系决定了在文件共享方面一个进程对另一个进程可能产生的影响。
& (1) 每个进程在进程表中都有一个记录项，记录项中包含有一张打开文件描述符表，可将其视为一个矢量，每个描述符占用一项。与每个文件描述符相关联的是：
& & & (a) 文件描述符标识（close_on_exec）。
& & &（b）指向一个文件表项的指针。
& （2）内核为所有的打开文件维持一张文件表。每个文件表项包含：
& & & （a）文件状态标志（读、写、添加、同步和非阻塞等）。
& & & （b）当前文件偏移量。
& & & （c）指向该文件v节点的指针。
& &（3）每个打开文件（或设备）都有一个v节点（v-node）结构。v节点包含了文件类型和对此文件进行各种操作的函数的指针。对于大多数文件，v节点还包含了该文件的i节点（i-node,索引节点）。这些信息是在打开文件时从磁盘上读入内存的，所以所有关于文件的信息都是快速可供使用的。例如，i节点包含了文件的所有者，文件长度，文件所在的设备，指向文件实际数据块在磁盘上所在位置的指针等等。
& & 注意：Linux没有使用v节点，而是使用了通用i节点结构。虽然两种实现有所不同，但在概念上，v节点与i节点是一样的。两者都指向文件系统特有的i节点结构。
& & 我们忽略了默写实现细节，但这并不影响我们的讨论。例如，打开文件描述符表可存放在用户控件，而非进程表中。这些表也可以用于多种方式的实现，不必一定是数组；例如，可将它们实现为结构的连接表。这些细节并不影响我们在文件共享方面的讨论。
& & 图1显示了一个进程的三张表之间的关系。该进程有两个不同的打开文件：一个文件打开为标注输入（文件描述符为0），另一个打开为标准输出（文件描述符为1）。从Unix系统的早期版本中[Thompson 1978]以来，这三张表之间的基本关系一直保持至今。这种安排对于在不同进程之间共享文件的方式非常重要。
& & & & & & & & & & & & & & & & & & & & 图1 打开文件的内核数据结构
注意：创建v节点结构的目的是对在一个计算机系统上的多文件系统类型提供支持。这一工作是有Peter Weihberger(贝尔实验室)和Bill Joy(Sun公司)分别独立完成的。Sun称此种文件系统为虚拟文件系统(Virtual File System)，称与文件系统类型无关的i节点部分为v节点[Kleiman 1986].当哥哥制造商的实现增加了对Sun的网络文件系统(NFS)的支持时，它们都广泛采用了v节点结构。在BSD系统中首先提供v节点的是4.3BSD Reno版本，其中加入了NFS。
在SVR4中，v节点代换了SVR3中与文件系统类型无关的i节点结构。Solaris是从SVR4发展而来的，他也是用了v节点。
Linux没有将相关的数据结构分为i节点和v节点，而是采用了一个独立于文件系统的i节点和一个依赖于文件系统的i节点。
&&&& 如果两个独立进程各自打开了同一个文件，则有图2中所示的安排。我们假设第一个进程在文件描述符3上打开该文件，而另一个进程则在文件描述4上打开该文件。打开该文件的每一个进程都得到一个文件表项，但对一个给定的文件只有一个v节点表项。每个进程都有自己的文件表项的一个理由是：这种安排使每一个进程都有它自己的对该文件的当前偏移量。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&图2 两个独立进程各自打开同一个文件&
&& &给出了这种数据结构后，现在对前面所描述的操作做进一步说明。&&&
在完成每个write后，在文件表项中的当前文件偏移量即增加所写的字节数。如果当前文件偏移量超过了当前文件长度，则在i节点表项中的当前文件长度被设置为当前文件的偏移量。
如果用O_APPEND标志打开了一个文件，则相应标志也被设置到文件表项的文件状态标志中。每次对这种具有添写标志的文件执行写操作时，在文件表项中的当前文件偏移量首先被设置为i节点表项中的文件长度。这就使得每次写的数据都添加到文件的当前尾端处。
若一个文件用lseek定位到文件当前的尾端，则文件表项中的当前文件偏移量被设置为i节点表项中的当前文件长度。注意，这与用O_APPEND标志打开文件是不同的。
sleek函数只修改文件表项中的当前文件偏移量，没有进行任何文件I/O操作。
&&& 可能有多个文件描述符指向同一个文件表项。在下一小节中讨论dup函数时，我们将能看见这一点。函数调用fork后产生的父子进程中，它们共享相同的i或v节点和同一个文件表项。（通过在现代Linux系统中进行测试得到的，测试程序和结构见下文（更正：测试结果分析有误！已更正！））。
&&& 注意，文件描述符标志和文件状态标志在作用域方面的区别，前者只用于一个进程的一个描述符，而后者适用于指向该给定文件表项的任何进程中的所有描述符。上面所述的一切对多个进程读同一个文件都能正确工作。每个进程都有它自己的文件表项，其中也有它自己的当前文件偏移量。但是，当多个进程写同一个文件时，则可能产生预期不到得结果。为了说明如何避免这种情况，我们需要理解原子操作的概念。
2. 原子操作
2.1 添写至一个文件
&&& 考虑一个进程，它要将数据添加到一个文件尾端。早期的UNIX系统版本并不支持open的O_APPEND选项，所以程序被编写成下列形式：
if (lseek(fd, 0L, 2) < 0) /* position to EOF */
&&&&err_sys("lseek error");
if (write(fd, buf, 100) != 100) /* and write */
&&&&err_sys("write error");
&&& 对单个进程而言，这段程序能正常工作，但若对多个进程同时使用这种方法将数据添加到同一文件，则会产生问题。（例如，若此程序由多个进程同时执行，各自将消息添加到一个日志文件中，就会产生这种情况。）
&&& 假定有两个独立的进程A和B都对同一个文件进行操作，给个进程都已打开了该文件，但未使用O_APPEND标志。此时，各数据结构之间的关系如图2所示。每个进程都有自己的文件表项，但是共享一个v节点表项。假定进程A调用了lseek，它将进程A的该文件当前偏移量设置为1500字节（当前文件尾端处）。然后内核调度进程使进程B运行。进程B执行sleek，也将其对该文件的当前偏移量设置为1500字节（当前文件尾端处）。然后B调用write函数，它将B的该文件当前文件偏移量增值1600.引文该文件的长度已经增加了，所以内核对v节点中的当前文件长度更新为1600.然后，内核又进行进程切换使进程A恢复运行。当A调用write时，就从其当前文件偏移量（1500字节）处将数据写到文件中去。这样就代换了进程B刚写到该文件中的数据。
&&&& 问题出在逻辑操作“定位到文件尾端处，然后写”上，它使用了两个分开的函数调用。解决问题的方法是使这两个操作对于其他进程而言成为一个原子操作。任何一个需要多个函数调用的操作都不可能是原子操作，因为在两个函数调用之间，内核有可能会临时挂起该进程。
&&&& UNIX系统提供了一种方法是这种操作成为原子操作，该方法是在打开文件时设置O_APPEND标志。正如前面所述，这就是内核每次对这种文件进行写之前，都将进程的当前偏移量设置到文件的尾端处，于是在每次写之前就不在需要调用sleek了。
2.2 pread和pwrite函数
&&&& Single UNIX Specification包括了XSI扩展，该扩展允许原子性地定位搜索（seek）和执行I(/O。pread和pwrite就是这种扩展。
#include <unistd.h>
ssize_t pread(int filedes, void *buf, size_t nbytes, off_t offset);
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&返回值：读到的字节数，若已到文件结尾则返回0，若出现错误返回-1
ssize_t pwrite(int filedes, const void *buf, size_t nbytes, off_t offset);
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&返回值：若成功则返回已写的字节数，若出错则返回-1
&&& 调用pread相当于顺序调用lseek和read，但是pread又与这种顺序调用有下列重要区别：
调用pread时，无法中断其定位和读操作。
不更新文件指针。
&&& 调用pwrite相当于顺序调用lseek和write，但也和它们有类似的区别。
2.3 创建一个文件
&&& 在对open函数的O_CREAT和O_EXCL选项进行说明时，我们已经见到另一个有关原子操作的例子。当同时指定这两个选项，而该文件又已经存在时，open将失败。我们曾提及检查该文件是否存在以及创建该文件这两个操作是作为一个原子操作执行的。如果没有这样一个原子操作，那么可能会编写下面的程序段：
if ((fd = open(pathname, O_WRONLY)) < 0) {
&&&&if (errno == ENOENT) {
&&&&&&&&&if ((fd = creat(pathname, mode)) < 0)
&&&&&&&&&&&&&&err_sys("create error");
&&&&} else {
&&&&&&&&&err_sys("open error");
&&&&&如果在open和creat之间，另一个进城创建了该文件，那么就会引起问题。例如，若在这两个函数调用之间。另一个进程创建了该文件，并且写进了一些数据，然后，原先的进程执行这段程序中的creat，这时，刚由另一个进程写上去的数据就会被擦除掉。如若将这两者合并在一个原子操作中，这种问题就不会存在了。
&&&& 一般而言，原子操作(atomic operation)指的是由多步组成的操作，如果该操作原子地执行，则要么执行完所有步骤，要么一步也不执行，不可能只执行所有步骤的一个子集。
3. dup和dup2函数
&&&& 下面两个函数都可用来复制一个现存的文件描述符：
#include <unistd.h>
int dup(int filedes);
int dup2(int filedes, int filedes2);
&&&&&&&&&&&&&&&&&&&&&两函数的返回值：若成功则返回新的文件描述符，若出错则返回-1
&&&&& 由dup返回的新文件符一定是当前可用文件描述符中的最小数值。用dup2则可以用filedes2参数指定新描述符的数值。如果filedes2已经打开，则先将其关闭。如若filedes等于filedes2,则dup2返回filedes2,而不关闭它。
&&&&& 这些函数返回的新文件描述符与参数参数filesdes共享同一个文件表项。如图3所示。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 图3 执行dup之后的内核数据结构
&&& 在图3中，我们假定进程执行了：
newfd = dup(1);
&&& 当此函数开始执行时，假定下一个可用的文件描述是3（这是非常有可能的，因为0、1、2是由shell打开的）。因为两个描述符指向同一文件表项，所以它们共享同一个文件状态标志（读、写、添加等）以及同一文件当前偏移量。
&&&&每个文件描述符都有它自己的一套文件描述符标志。新描述的执行时关闭(close-on-exec)标志总是由dup函数清除。
&&&&复制一个描述符的另一种方法是使用fcntl函数，实际上，调用
dup(filedes);
dup2(filedes, F_DUPFD, 0);
dup2(filedes, filedes2);
close(filedes2);
fcntl(filedes, F_DUPFD, filedes2);
在后一种情况下，dup2并不完全等同于close()加上fcntl.它们之间的区别是：
dup2是一个原子操作，而close及fcntl则包含两个函数调用。有可能在close和fcntl之间插入执行信号捕获函数，它可能修改文件描述符。
dup2和fcntl有某些不同的errno。
4. 测试结果&&
&&& 带有O_APPEND标志的测试代码和结果数据如下：&&&
&&&&没有带O_APPEND标志的测试代码和结果数据如下：&&
&&& 可以看到，o_append_text.rar里面的测试结果数据文件大小是test.rar里面的2倍。分析其原因，是因为函数调用fork时，在父子进程中没有为他们采取必要的同步措施，因此在写文件时有竞争发生，导致结果混乱。另外，文件大小的不同是因为，文件表项中的文件偏移量的值类型并不是一个易失形变量类型，从而导致在写文件时读取的偏移值变量的值不是最新的值，从而导致文件大小会不同的结果。
&&&&另外，从结果数据中（可能数据没有充分表现出如下所说的情况，但是你可以通过调整测试程序里的参数，并多运行几次测试程序就可以得到如下所述的结果）可以得出：当以O_APPEND标志打开文件时，write将执行原子操作，read亦然。而没有使用O_APPEND标志打开文件时，父子进程的数据输出将出现乱序的情况。
阅读(18153) | 评论(1) | 转发(0) |
上一篇：没有了
相关热门文章
给主人留下些什么吧！~~
“然后B调用write函数，它将B的该文件当前文件偏移量增值1600.引文该文件的长度已经增加了”你是说A先lseek到1500，然后B&lseek到1500，后写入了100字节，然后A从1500处开始写吗？谢谢
请登录后评论。SharedPreferences在多进程中的使用及注意事项 - 推酷
SharedPreferences在多进程中的使用及注意事项
### 通过SharedPreferences实现进程间数据共享
之前为了解决应用的内存压力，在同一个应用中使用了多进程，但在程序自测的过程中发现不同进程之间的SharedPreferences数据不能共享，但应用内很多数据都是通过SharedPreferences来保存的，如果改成其它多进程通信的方式改动比较大。通过查看源码发现，在API Level&=11即Android 3.0可以通过Context.MODE_MULTI_PROCESS属性来实现SharedPreferences多进程共享，具体使用方式如下：
public class PreferencesUtils {
public static String PREFERENCE_NAME = &SharedPreferencesDemo&;
private PreferencesUtils(){
public static boolean putString(Context context, String key, String value) {
SharedPreferences settings = context.getSharedPreferences(PREFERENCE_NAME, Context.MODE_MULTI_PROCESS);
SharedPreferences.Editor editor = settings.edit();
editor.putString(key, value);
public static String getString(Context context, String key, String defaultValue) {
SharedPreferences settings = context.getSharedPreferences(PREFERENCE_NAME, Context.MODE_MULTI_PROCESS);
return settings.getString(key, defaultValue);
SharedPreferences时间进程间数据共享会导致的问题
本来以为通过MODE_MULTI_PROCESS属性使用SharedPreferences就可以解决不同进程之间不能共享数据的问题了，但SQA总是反馈一些随机但出现频率比较大的bug，比如在使用过程中没有清除程序数据的前提下，会出现欢迎界面和操作指引，这是通过保存在SharedPreferences的标志来判断用户是否是第一次启动程序的，分析发现保存在SharedPreferences中的数据丢失了，但代码中并没有去清除这些数据，所以推测可能是不同进程同一时间对SharedPreferences操作导致的，经验证确实如此，去掉多进程就不会再出现这个问题了。
由于进程间是不能内存共享的，每个进程操作的SharedPreferences都是一个单独的实例，上述的问题并不能通过锁来解决，这导致了多进程间通过SharedPreferences来共享数据是不安全的，这个问题只能通过多进程间其它的通信方式或者是在确保不会同时操作SharedPreferences数据的前提下使用SharedPreferences来解决。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:11&分页:红魔 | 抠腚王子发信人: codingprince (红魔 | 抠腚王子), 信区: LinuxDev
标&&题: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 10:47:40 2015), 站内 && 问题再简化一点：如何做到在第一个so加载的时候在内存中做个标记，然后让后面加载的so可以判断该标记是否已经被设置了？ && --
抠得一手好腚 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 61.135.169.*]
梦醒时分发信人: Knightmare (梦醒时分), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 15:29:17 2015), 站内 && semaphore ?
【 在 codingprince (红魔 | 抠腚王子) 的大作中提到: 】
: 标&&题: 如何让同一进程中不同的so共享一个数据？
: 发信站: 水木社区 (Mon Mar 16 10:47:40 2015), 站内
: 问题再简化一点：如何做到在第一个so加载的时候在内存中做个标记，然后让后面加载的so可以判断该标记是否已经被设置了？
: 抠得一手好腚
: ※ 来源:·水木社区 newsmth.net·[FROM: 61.135.169.*]
&&&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 221.218.156.*]
MH730发信人: MH730 (MH730), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 16:01:29 2015), 站内 && 最简单的全局变量
【 在 codingprince 的大作中提到: 】
: 问题再简化一点：如何做到在第一个so加载的时候在内存中做个标记，然后让后面加载的so可以判断该标记是否已经被设置了？
-- && ※ 来源:·水木社区 ·[FROM: 61.139.22.*]
红魔 | 抠腚王子发信人: codingprince (红魔 | 抠腚王子), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 16:36:38 2015), 站内 && 这个全局变量没地方定义啊，每个so自己定义的话就冲突了，另外也不知道哪个so会先加载进来 && 刚想到可以用环境变量来做 && 【 在 MH730 (MH730) 的大作中提到: 】
: 最简单的全局变量
抠得一手好腚 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 61.135.169.*]
劣币驱逐良币 | 少灌水发信人: vonNeumann (劣币驱逐良币 | 少灌水), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 16:44:00 2015), 站内 && 环境变量可不是全局的 &&&& 【 在 codingprince (红魔 | 抠腚王子) 的大作中提到: 】
: 这个全局变量没地方定义啊，每个so自己定义的话就冲突了，另外也不知道哪个so会先加载进来
: 刚想到可以用环境变量来做
&&&& -- && ＧＦＤＳＡ&&ＨＪＫＬＭ&&ＴＲＥＷＱ&&ＹＵＩＯＰ&&ＮＢＶＣＸ
王土大木工&&目日口田山&&禾白月人金&&言立水火之&&已子女又纟
一地在要工&&上是中国同&&和的有人我&&主产不为这&&民了发以经 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 211.99.222.*]
红魔 | 抠腚王子发信人: codingprince (红魔 | 抠腚王子), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 17:57:17 2015), 站内 && 同一进程
【 在 vonNeumann (劣币驱逐良币 | 少灌水) 的大作中提到: 】
: 环境变量可不是全局的
抠得一手好腚 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 61.135.169.*]
劣币驱逐良币 | 少灌水发信人: vonNeumann (劣币驱逐良币 | 少灌水), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Mon Mar 16 18:04:43 2015), 站内 && 哦.. && 我还以为是不同进程.. 同一个进程的话，这个需求比较奇怪.. 不知道你的原始需求是啥.. &&&& 【 在 codingprince (红魔 | 抠腚王子) 的大作中提到: 】
: 同一进程
&&&& -- && ＧＦＤＳＡ&&ＨＪＫＬＭ&&ＴＲＥＷＱ&&ＹＵＩＯＰ&&ＮＢＶＣＸ
王土大木工&&目日口田山&&禾白月人金&&言立水火之&&已子女又纟
一地在要工&&上是中国同&&和的有人我&&主产不为这&&民了发以经 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 211.99.222.*]
coly发信人: colyli (coly), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Tue Mar 17 01:20:45 2015), 站内 && 如果这些so是你自己写的话，可以用全局变量，没问题。在so里引用这个全局变量的地方，将这个变量用关键字extern声明为外部变量，这样这个变量名的符号会被编译链接成弱符号。当so被动态加载时，这个弱符号会被动态链接器在当前进程的名字空间中进行检索，如果检索成功就会被解析到你在主程序中定义该全局变量的地址上。如果解析失败，那就是程序哪里写好或者编译的时候漏了什么地方。 &&&& 【 在 codingprince 的大作中提到: 】
: 问题再简化一点：如何做到在第一个so加载的时候在内存中做个标记，然后让后面加载的so可以判断该标记是否已经被设置了？
============================= &&&& &&&&&& ============================= && ※ 来源:·水木社区 ·[FROM: 123.122.101.*]
红魔 | 抠腚王子发信人: codingprince (红魔 | 抠腚王子), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Tue Mar 17 18:33:31 2015), 站内 && 主程序不是我的，所有的so都是我的，这些so也没有固定的加载顺序 && 【 在 colyli (coly) 的大作中提到: 】
: 如果这些so是你自己写的话，可以用全局变量，没问题。在so里引用这个全局变量的地方，将这个变量用关键字extern声明为外部变量，这样这个变量名的符号会被编译链接成弱符号。当so被动态加载时，这个弱符号会被动态链接器在当前进程的名字空间中进行检索，如果检索成功就
抠得一手好腚 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 61.135.169.*]
劣币驱逐良币 | 少灌水发信人: vonNeumann (劣币驱逐良币 | 少灌水), 信区: LinuxDev
标&&题: Re: 如何让同一进程中不同的so共享一个数据？
发信站: 水木社区 (Tue Mar 17 18:34:12 2015), 站内 && a.so 如果要用 b.so 的东西的话，链接 a.so 的时候就要加 -lb，这样 b.so 自然比 a.so 先加载。不会控制不了加载顺序啊 &&&& 【 在 codingprince (红魔 | 抠腚王子) 的大作中提到: 】
: 主程序不是我的，所有的so都是我的，这些so也没有固定的加载顺序
&&&& -- &&&&Across the Great Fire Wall we can reach every corner in the world. &&&& ※ 修改:·vonNeumann 于 Mar 17 18:34:37 2015 修改本文·[FROM: 211.99.222.*]
※ 来源:·水木社区 newsmth.net·[FROM: 211.99.222.*]
文章数:11&分页: