Pakiet programów do zdalnego nauczania Programowania Orientowanego Obiektowo
Dzisiaj jest
Środa, 18 Lipiec 2018
Zarejestrowanych użytkowników: 4
Dostępnych pytań testowych: 102
HOME
Strona tytułowa pracy dyplomowej
NAUKA
Materiały dydaktyczne związane z OOP
TESTY
Sprawdzenie poziomu zdobytej wiedzy
ZASOBY
Literatura i zasoby sieciowe o OOP
ŹRÓDŁA
Zbiór projektów dydaktycznych z OOP
KONTO
Możliwość śledzenia własnych postępów
INFO



Singleton a wielowątkowość

W przypadku projektowania aplikacji korzystającej z wielu wątków należy zabezpieczyć się przed sytuacją w którym dwa lub więcej wątków próbuje w tej samej chwili skorzystać z metody egzemplarz tuż przed utworzeniem go. W szczególnym przypadku może dojść do sytuacji w której oba wątki w tym samym momencie przejdą przez instrukcję warunkową sprawdzającą istnienie egzemplarza (gdy nie jest on jeszcze utworzony), co spowoduje że oba wątki utworzą ów egzemplarz.

Generator * Generator::egzemplarz () {
	if (s_egzemplarz == 0)
		s_egzemplarz = new Generator();

	return s_egzemplarz;
}

Mimo, że jest to sytuacja bardzo mało prawdopodobna to należy się przed nią zabezpieczyć. Jedną z możliwości jest założenie odpowiednich blokad w ciele funkcji, które spowodują że w danym momencie tylko jeden wątek będzie mógł korzystać z funkcji. Wadą takiego rozwiązania jest narzut czasowy związany z obsługą blokad.

Drugim sposobem jest tworzenie pojedynczego egzemplarza już w definicji zmiennej prywatnej wskazującej na egzemplarz:

Generator * Generator::s_egzemplarz = new Generator();

i zmiana implementacji metody egzemplarz() na następującą:

Generator * Generator::egzemplarz () {
	return s_egzemplarz;
}

W tym wypadku wada to ograniczona możliwość reakcji na wyjątek rzucony przez konstruktor klasy Generator niż w przykładzie poprzednim. Twórca takiej klasy może co najwyżej wyłapać wyjątek na poziomie konstruktora i zdecydować np. o zamknięciu aplikacji. Łapanie wyjątków na zewnątrz klasy (w tym wypadku niemożliwe z powodu niemożności umieszczenia klauzuli try-catch w zasięgu globalnym) daje większe możliwości, ponieważ klient w zależności od kontekstu aplikacji może podjąć bardziej przemyślane działania niż twórca klasy.

Adamik Łukasz, Politechnika Śląska w Gliwicach (AEiI) - 2010/11