Cześć,
W części 6 poświęconej temacie wątków omówiłem temat klasy „CountDownLatch”. Przypominając, „CountDownLatch”to jeden z wielu mechanizmów, narzędzi służących do synchronizacji wątków. W całej serii zostały omówione już:
- synchronized: aby przeczytać post, kliknij tutaj.
- semaphore: aby przeczytać post, kliknij tutaj.
- lock: aby przeczytać post, kliknij tutaj.
- countdownlatch: aby przeczytać post, kliknij tutaj.
Dzisiaj chciałbym przybliżyć Wam klasę „CyclicBarrier”, powszechniej znane pod hasłem: Barriery, który również jest mechanizmem służącym do synchronizacji kodu / wątków. Do dzieła!
Wstęp
Klasę „CyclicBarrier”od zawsze kojarzę bezpośrednio z polskim słowem: bariera. Wyobrażam sobie, że do uruchomienia sekwencji wątków musi zostać osiągnięta pewna bariera (liczba) wątków. Mówiąc prościej: klasy „CyclicBarrier” używamy w momencie, kiedy chcemy pogrupować daną liczbę wątków w taki sposób, by wykonywały pracę w określonej liczbie w określonym czasie.
„CyclicBarrier” jest synchronizatorem, który pozwala zestawowi wątków czekać na siebie nawzajem. Barriery używane są w programach, w którym musimy ustalić liczbę wątków, które muszą czekać na siebie nawzajem, aby osiągnąć wspólny punkt czy cel przed kontynuowaniem wywołania.
Skąd nazwa Cyclic? Ponieważ pula wątków może być ponownie użyta po zwolnieniu oczekujących wątków.
Użycie
Konstruktor dla klasy CyclicBarrier jest prosty. W parametrze posiada liczbę całkowitą oznaczającą liczbę wątków, które musza wywołać metodę „await()” na instancji barriery, aby zasygnalizować osignięcie wspólnego punktu wywołania:
Wywołanie Barriery jest synchroniczne i wątek wywołujący tę metodę zawiesza jej wykonanie do momentu, aż określona liczba wątków wywoła tę samą metodę na barierze. Sytuacja, w której wymagana liczba wątków wywołała „await()” nazywana jest punktem zwrotnym.
Opcjonalnie możemy również jako drugi parametr do konstruktora przekazać obiekt Runnable. Posiada on logikę, która zostanie uruchomiona przez ostatni wątek, który „potknie” się o Barriere (czyli nasz punkt zwrotny).
Przykład praktyczny
Tradycyjnie, w celu lepszego zrozumienia tematu chciałbym zaprezentować Wam historię z życia. Wyobraźmy sobie wyjście do muzeum i zwiedzanie. Czasami zdarza się, że przewodnik może rozpocząć zwiedzanie dopiero po osiągnięciu określonej liczby osób. To wszystko po to, by w pełni wykorzystać zasoby i pracowników. Dlatego grupa z przewodnikiem rozpoczyna zwiedzanie dopiero wtedy, kiedy znajdzie się pełna grupa – na przykład 10 osób. W momencie kiedy jest mniej niż zdeklarowana liczba osób, to czekamy aż inni zakupią bilet i wyrażą chęć zwiedzania. Spójrzmy na kod:
Jeśli chcielibyśmy pogrupować zwiedzających i tym podobne, również jest taka możliwość. Za pomocą klasy „CyclicBarrier” można kontrolować kiedy dane obliczenia zostaną wykonane.
Ważną cechą, która charakteryzuje „CyclicBarrier”w porównaniu np. do wcześniej omawianego „CountDownLatch” jest fakt, że w przypadku Latchy to dodatkowy wątek blokował się aż wszystkie wątki zakończą pracę. Jeśli chodzi o „CyclicBarrier” to wątki, które wykonały swoją pracę czekają na pozostałe. Po zakończeniu wykonywania pracy przez wszystkie wątki uruchamiane jest nowe zadanie.
Reasumując: Kiedy „CyclicBarrier” osiągnie określony próg zostają automatycznie resetowane. W Latchach po osiągnięciu takiego progu powoduje to uruchomienie mechanizmu już na zawsze .
Podsumowanie
W artykule przedstawiłem, czym jest „CyclicBarrier” i w jakich sytuacjach może się przydać. Został zaimplementowany prosty kod, w którym potrzebowaliśmy ustalonej liczby wątków, aby osiągnąć ustalony punkt wykonania, przed kontynuowaniem innej logiki programu. I tym samym dobrnęliśmy do końca serii o wielowątkowości. Jak widać, w Javie mamy dostępnych wiele mechanizmów do synchronizacji pracy wątków. Zdaję sobie sprawy, że na co dzień nie zdarza się nam z nich regularnie korzystać ale warto być świadomy, ze coś takiego istnieje. Mam nadzieje, że cała seria o wątkach oraz wielowątkowości (aż 7 postów) przypadła Wam do gustu. Za tydzień tradycyjnie wpis o tematyce biegowej ale już za dwa tygodnie „widzimy się” bardziej technicznie.
Pozdrawiam serdecznie,
biegajacyprogramista.pl
