我應該在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之前鎖定嗎？

回答

相關問題