Udostępnianie pamięci między modułami

Question

Zastanawiam się, jak udostępnić trochę pamięci między różnymi modułami programu - powiedzmy, mam główną aplikację (exe), a następnie jakiś moduł (dll). Obaj łączą się z tą samą biblioteką statyczną. Ta biblioteka statyczna będzie miała jakiegoś menedżera, który zapewnia różne usługi. To, co chciałbym osiągnąć, to udostępnienie tego menedżera między wszystkimi modułami aplikacji i wykonanie tego w sposób przezroczysty podczas inicjowania biblioteki. Pomiędzy procesami mógłbym używać pamięci współdzielonej, ale chcę, aby była ona udostępniana tylko w bieżącym procesie. Czy możesz wymyślić jakiś sposób między platformami, aby to zrobić? Ewentualnie za pomocą bibliotek doładowania, jeśli zapewniają pewne możliwości, aby to zrobić.

Jedyne rozwiązanie, o jakim teraz pomyślę, to korzystanie z biblioteki współdzielonej odpowiedniego systemu operacyjnego, z której wszystkie inne moduły będą łączyły się w czasie wykonywania, i tam zapisano menedżera.

EDIT: Aby wyjaśnić, co tak naprawdę potrzebne:

1. muszę dowiedzieć się, czy wspólny menedżer został już utworzony (odpowiedzi poniżej już przewidzianych kilka sposobów, aby to zrobić)
2. Pobierz wskaźnik do menedżera, jeśli istnieje, lub Ustaw wskaźnik gdzieś do nowo utworzonego obiektu zarządzania.

Answer 1

Myślę, że będziesz potrzebować pomocy z udostępnionej biblioteki, aby zrobić to w dowolny przenośny sposób. Nie musi koniecznie wiedzieć nic o obiektach współużytkowanych między modułami, po prostu musi dostarczyć trochę globalnie dostępnego mapowania z klucza (prawdopodobnie łańcucha) do wskaźnika.

Jeśli jednak chcesz wywoływać interfejsy API systemu operacyjnego, jest to możliwe i myślę, że możesz potrzebować tylko dwóch implementacji części specyficznej dla systemu operacyjnego (jedna dla bibliotek DLL systemu Windows i GetProcAddress, jedna dla systemów operacyjnych korzystających z dlopen) .

Podczas ładowania każdego modułu przechodzi listę wcześniej załadowanych modułów, szukając dowolnego, który eksportuje specjalnie nazwaną funkcję. Jeśli znajdzie jeden (dowolny, nie ma znaczenia który, ponieważ niezmiennikiem jest to, że wszystkie w pełni załadowane moduły są świadome wspólnego obiektu), pobiera adres wspólnego obiektu z wczytanego wcześniej modułu, a następnie zwiększa liczbę odwołań . Jeśli nie można go znaleźć, przydziela nowe dane i inicjuje licznik odwołań. Podczas rozładowywania modułu zmniejsza on liczbę odwołań i zwalnia wspólny obiekt, jeśli licznik odwołań wyniósł zero.

Oczywiście konieczne jest użycie podzielnika systemu operacyjnego dla wspólnego obiektu, ponieważ chociaż jest to mało prawdopodobne, możliwe jest, że został zwolniony z innej biblioteki niż ta, która została po raz pierwszy załadowana. Oznacza to również, że wspólny obiekt nie może zawierać żadnych funkcji wirtualnych ani żadnego innego rodzaju wskaźnika do segmentów różnych modułów. Wszystkie jego zasoby muszą być przydzielane dynamicznie przy użyciu przydziału dla całego systemu operacyjnego. Jest to prawdopodobnie mniej obciążające systemy, w których libC++ jest biblioteką współdzieloną, ale powiedziałeś, że łączysz statycznie CRT.

funkcje potrzebne w Win32 obejmowałyby EnumProcessModules, GetProcAddress, HeapAlloc i HeapFree, GetProcessHeap i GetCurrentProcess.

Wszystko, co uważam, myślę, że trzymałbym się umieszczania wspólnego obiektu we własnej bibliotece współdzielonej, która wykorzystuje struktury danych modułu ładującego, aby go znaleźć. W przeciwnym razie ponownie wynajdujesz program ładujący. To zadziała nawet wtedy, gdy CRT jest statycznie połączony z kilkoma modułami, ale myślę, że ustawiasz się na naruszenia ODR. Bądź naprawdę konkretny w utrzymywaniu wspólnych danych POD.

Answer 2

Można użyć boost::interprocesshttp://www.boost.org/doc/libs/1_45_0/doc/html/interprocess.html i Windows można utworzyć wspólny segment w swojej biblioteki DLL, które będą wspólne dla wszystkich procesów wykorzystujących # pragma to: http://www.codeproject.com/KB/DLL/data_seg_share.aspx

Answer 3

do wykorzystania od bieżącego procesu tylko, don Trzeba opracować jakąś specjalną funkcję lub strukturę.

Można to zrobić nawet bez żadnej funkcji, ale jest bardziej bezpieczny i przyjazny dla platformy, aby zdefiniować zestaw funkcji zapewniających dostęp do udostępnionych danych. Te funkcje mogą być implementowane przez wspólną bibliotekę statyczną.

Wydaje mi się, że jedynym problemem związanym z tą konfiguracją jest: "Kto będzie właścicielem danych?". Musi istnieć jeden i tylko jeden właściciel udostępnianych danych.

Z tych podstawowych idei, moglibyśmy naszkicować API tak:

IsSharedDataExist  // check whether of not shared data exist 

CreateSharedData  // create (possibly dynamically) shared data 

DestroySharedData  // destroy shared data 

... various data access API ... 

lub C++ klasy z wzorca Singleton będzie właściwe.

---

UPDATE

byłem zdezorientowany. Prawdziwy problem można zdefiniować jako "Jak zaimplementować klasę Singleton w bibliotece statycznej, która będzie połączona z wieloma bibliotekami dynamicznego ładowania (będzie używana w tym samym procesie) w sposób niezależny od platformy".

Myślę, że podstawowy pomysł nie jest różny, ale upewnij się, że singleton jest naprawdę singielkiem, to dodatkowy problem w tej konfiguracji.

W tym celu można skorzystać z Boost.Interprocess.

#include <boost/config.hpp> 
#include <boost/interprocess/sync/named_mutex.hpp> 
... 
boost::interprocess::named_mutex* singleton_check = 0; 

// in the Create function of the singleton 
try { 
    singleton_check = new boost::interprocess::named_mutex(boost::interprocess::create_only, "name_of_the_mutex"); 
    // if no exception throw, this is the first time execution 
} 
catch (...) 
{ 
} 

Uwolnienie named_mutex jest tak proste jak delete singleton_check.

---

UPDATE # 2

Kolejna propozycja.

Myślę, że nie powinniśmy umieszczać wspólnych danych we wspólnej bibliotece statycznej. Jeśli nie możemy zapewnić globalnie unikalnych danych, to nie tylko trudne problemy z implementacją zależą od platformy, ale także marnowanie pamięci i zasobów globalnych.

Jeśli wolisz korzystać z biblioteki statycznej, powinieneś utworzyć dwie statyczne biblioteki. Jeden dla serwera/twórcy udostępnionych danych, jeden dla użytkowników udostępnionych danych. Biblioteka serwerów definiuje i zapewnia dostęp do Singleton. Biblioteka klientów udostępnia różne metody dostępu do danych.

Jest to faktycznie to samo, co implementacja Singleton bez bibliotek statycznych.

Answer 4

Zgodnie MSDN widzę istnieją tylko dwa sposoby udostępniania danych pomiędzy modułami

1. Korzystanie data_seg pragmy
2. korzystają z pamięci współdzielonej.

Jak wskazano, segment współdzielony działa tylko dla dwóch wystąpień tej samej biblioteki dll, więc pozostaje nam tylko jedna możliwość użycia techniki mapowania pamięci.