Zapisywanie klasy C++, która może być używana jako statyczna, ale wymaga blokady

Question

Potrzebuję napisać klasę, która ładuje biblioteki współdzielone. Sekwencja dlopen()/dlerror() potrzebuje blokady, aby była bezpieczna dla wątków.

class LibLoader { 
    public: 
    LibLoader(string whichLib); 
    bool Load() { Wait(lock); ... dlopen() ... dlerror() ... } 
    bool Unload() { Wait(lock); ... dlclose() ... dlerror() ... } 
    bool IsLoaded() {...} 
    // ... access to symbols... 
    private: 
    static Lock lock; 
} 
Lock Lock::lock; 

Użytkownicy tej klasy (nie będzie wielokrotnością w tym samym czasie) będzie chciał, aby to statyczne członkiem tej klasy, aby uniknąć ładowania wspólna Biblioteka czas dla każdego obiektu klasy:

class NeedsALib { 
public: 
NeedsALib() { if (!myLib.IsLoaded()) { myLib.Load(); } } 
private: 
static LibLoader myLib; 
} 
LibLoader::myLib; 

Problem z tym kodem polega na tym, że może się zawieść, ponieważ opiera się na kolejności niszczenia statyki po zakończeniu programu. Jeśli blokada zniknie, zanim myLib się zawiesza ...

Jak można to napisać w bezpieczny sposób, który jest bezpieczny dla wątków i nie polega na kolejności statycznego zniszczenia?

Answer 1

Niestety, wydaje mi się, że jedynym sposobem na uniknięcie tego jest użycie nieprzewidywalnych jednorazowych dyrektyw inicjalizacyjnych i uniknięcie w ogóle zniszczenia zamka. Są dwa podstawowe problemy, z którymi musisz sobie poradzić:

1. Co się stanie, jeśli dwa wątki będą ścigały się, aby uzyskać dostęp do zamka po raz pierwszy? [tj. nie możesz leniwy - utwórz zamka]
2. Co się stanie, jeśli zamek zostanie zniszczony zbyt wcześnie? [tj. nie można statycznie utworzyć blokady]

Połączenie tych ograniczeń zmusza do użycia mechanizmu niemobilnego w celu utworzenia zamka.

Na pthreads, najprostszym sposobem radzenia sobie z tym jest, co pozwala statycznie zainicjować blokuje PTHREAD_MUTEX_INITIALIZER:

class LibLoader{ 
    static pthread_mutex_t mutex; 
// ... 
}; 

// never destroyed 
pthread_mutex_t LibLoader::mutex = PTHREAD_MUTEX_INITIALIZER; 

Z okien można użyć synchronous one-time initialization.

Alternatywnie, jeśli można Gwarantujemy, że będzie tylko jeden wątek przed głównych tras, można użyć Singleton bez zniszczenia, i po prostu zmusić blokadę być dotykane przed main():

class LibLoader { 
    class init_helper { 
    init_helper() { LibLoader::getLock(); } 
    }; 

    static init_helper _ih; 
    static Lock *_theLock; 

    static Lock *getLock() { 
    if (!_theLock) 
     _theLock = new Lock(); 
    return _theLock; 
    } 
    // ... 
}; 

static init_helper LibLoader::_ih; 
static Lock *LibLoader::_theLock; 

Zauważ, że to czyni możliwym nieprzenośne (ale bardzo prawdopodobne, że jest prawdziwe) założenie, że statyczne obiekty typu POD nie zostaną zniszczone, dopóki wszystkie statyczne obiekty nie-POD nie zostaną zniszczone. Nie jestem świadomy żadnej platformy, w której tak nie jest.

Answer 2

Zawijanie wymagań: potrzebnych jest wiele instancji LibLoader, każda dla innej biblioteki, ale musi istnieć pojedyncza blokada, aby zapewnić, że nie będą one nadpisywać kodów błędów drugiej strony.

Jednym ze sposobów jest poleganie na statycznej inicjalizacji i kolejności niszczenia w pliku.

Lepszym sposobem nie byłoby utworzenie statycznego pola LibLoader w NeedsALib (i tym podobne). Wygląda na to, że te klasy klientów mogą zostać przekazane instancji o odpowiedniej architekturze LibLoader w konstruktorze.

Jeśli tworzenie instancji poza swoimi klasami klienckimi nie jest wygodne, można utworzyć wszystkie wskaźniki statyczne (blokadę i ładowarki) i zastosować wzorzec singletowy z leniwą inicjalizacją. Następnie, podczas tworzenia pierwszego programu ładującego, kończy się także tworzenie blokady. Sam Singleton wymagałby zablokowania, ale możesz go uruchomić przed uruchomieniem wątków. Zniszczenie będzie również jawne i pod twoją kontrolą. Możesz to również zrobić tylko z ładowarkami (zachowując statyczną blokadę).

Ponadto, jeśli LibLoader nie ma dużo stanu do zapisania, można wykonać każdą klasę klienta (NeedsALib itd.), Aby utworzyć własną wersję LibLoader. Jest to wprawdzie dość marnotrawstwo.