我应该在dlopen之前锁定吗？

我确实有一个* .so库，它使用dlopen从系统库中获取一些信息。库可以被多个应用程序同时使用。也许这是一个愚蠢的问题，但我应该在图书馆做dlopen之前涌入图书馆吗？我没有在任何地方找到直接的答案。我应该在dlopen之前锁定吗？

2017-03-01 incogn1to

号的每个程序都使用自己的内存堆栈时，它加载库。锁定仅适用于*共享资源*，如果多个程序使用相同的共享库，则这是不存在的。 –

如果没有人修改文件，则不需要对文件进行植绒。 –

我更担心在文件系统上同时访问文件（库）。 – incogn1to

与评论中所述内容类似，除非您访问可能会改变您的共享资源，否则不需要信号灯（群）。（IE。访问共享内存并需要确保数据的并发性）。该方式动态加载... dlopen的（）...作品

Those two routines are actually simple wrappers that call back into the dynamic linker. When the dynamic linker loads a library via dlopen(), it does the same relocation and symbol resolution it does on any other library, so the dynamically loaded program can without any special arrangements call back to routines already loaded

的连接因作品，搬迁和修改GOT/PLT方式中的内存空间完成（进程调用dlopen）而不是共享对象映射的地方。

If a hundred processes use a shared library, it makes no sense to have 100 copies of the code in memory taking up space. If the code is completely read-only, and hence never, ever, modified

具有共享对象以只读你永远不必担心他们在你突然改变的sooo不需要羊群:)内存为！

注意：因为你有一个共享对象链接到其他共享对象......初始共享对象的GOT需要更新/ mod，并且使用dlopen（）加载库的重定位...但是存储在进程唯一内存空间的ar/w段中，而不是共享对象的ar/w段中。

the shared library must still have a unqiue data instance in each process...the read-write data section is always put at a known offset from the code section of the library. This way, via the magic of virtual-memory, every process sees its own data section but can share the unmodified code

来源

2017-03-01 17:43:51 Hedge7707

我应该在dlopen之前锁定吗？

回答

相关问题