Wielowątkowość 1. Marcin Orchel. AGH University of Science and Technology in Poland 1 / 58

Transkrypt

1 Wielowątkowość 1 Marcin Orchel AGH University of Science and Technology in Poland 1 / 58

2 Section 1 Agenda Agenda 2 / 58

3 1 Współbieżność 2 Synchronizacja 3 Zbiory oczekujące Agenda 3 / 58

4 Section 2 Współbieżność Współbieżność 4 / 58

5 Sekcja krytyczna sekcja krytyczna to część programu wielowątkowego, która nie może być równocześnie wykonywana przez więcej niż jeden wątek. Innymi słowy jest to część programu, która wymaga wzajemnego wykluczania (ang. mutual exclusion, mutex) dostępu. Z reguły sekcja krytyczna uzyskuje dostęp do zasobów współdzielonych. Sekcja krytyczna może składać się z wielu nie połączonych ze sobą bloków kodu. POSIX Threads (pthreads) model wielowątkowości niezależny od języka, API W systemie operacyjnym, możemy przykładowo uniemożliwić zmiany kontroli procesora przez wyłączenie przerwań przy wejściu do sekcji krytycznej, czyli uniemożliwieniu przełączania kontekstu. Po wyjściu ze sekcji krytycznej wykonywane są wszystkie oczekujące przerwania. Współbieżność 5 / 58

6 Blokada synchronizacja procesów to koncepcja w której wiele procesów musi się wymienić informacjami w pewnym czasie w celu dojścia do porozumienia lub dopuszczenia pewnej sekwencji akcji blokada (ang. lock) to mechanizm synchronizacji, który wymusza ograniczenie dostępu do zasobu w środowisku wielowątkowym. wyróżniamy blokady ściśle egzekwowane (ang. mandatory locks), dla takiej blokady jest rzucany wyjątek dla nieautoryzowanego dostępu do zasobu i blokady informujące (ang. advisory locks) gdzie wątek zajmuje wcześniej blokadę, przed dostępem do zasobu osobną kategorią są blokady dostępu do bazy danych, które mogą dotyczyć konkretnego rekordu, konkretnego pola, lub całej tabeli blokada za pomocą synchronized jest zwana intrinsic lock (wewnętrzna blokada) Współbieżność 6 / 58

7 Tworzenie wątków możliwość równoległego wykonywania wątków korzystających z pamięci współdzielonej. wątki reprezentowane są przez klasę Thread aby stworzyć wątek należy stworzyć obiekt klasy Thread wątek się uruchamia, kiedy zostanie wywołana metoda start() Współbieżność 7 / 58

8 Wątki w C++ wątek wykonania (wątek) to pojedynczy przepływ kontroli w programie, włącznie z początkowym wywołaniem funkcji najwyższego poziomu i rekursywnie włączanie wywołań każdej funkcji później wykonywanej przez ten wątek. Gdy jeden wątek tworzy kolejny, początkowe wywołanie funkcji wyższego poziomu nowego wątku jest wykonywane przez nowy wątek, a nie przez wątek tworzący. Każdy wątek w programie może potencjalnie mieć dostęp do każdego obiektu i funkcji w programie. Obiekt z automatycznym czasem życia (auto) lub wątkowym czasem życia (thread_local) jest powiązany tylko z jednym wątkiem, i może być dostępny dla innego wątku tylko pośrednio poprzez wskaźniki lub referencje W danej imlementacji program C++ może mieć więcej niż jeden wątek uruchomiony równolegle. Wykonanie całego programu polega na wykonaniu wszystkich jego wątków. To czy program może mieć więcej niż jeden wątek wykonania zależy od implementacji standardu. Współbieżność 8 / 58

9 Wątki w C++ Implementacja standardu powinna zapewniać, że wszystkie nieblokowane wątki w konsekwencji czynią postępy. Funkcje biblioteki standardowej mogą po cichu blokować się na wejściu/wyjściu lub blokadach. Czynniki w środowisku wykonawczym, włącznie z narzucanymi zewnętrznie priorytetami wątków mogą uniemożliwić implementacji zagwarantowanie dalszego postępu. Współbieżność 9 / 58

10 Metody tworzenia wątków Preferowaną metodą tworzenia wątku jest implementacja interfejsu Runnable. class PrimeThread extends Thread { long minprime; PrimeThread(long minprime) { this.minprime = minprime; public void run() { // compute primes larger than minprime... Współbieżność 10 / 58

11 Metody tworzenia wątków cd. wątek uruchamiamy za pomocą instrukcji PrimeThread p = new PrimeThread(143); p.start(); drugi sposób tworzenia wątków class PrimeRun implements Runnable { long minprime; PrimeRun(long minprime) { this.minprime = minprime; public void run() { // compute primes larger than minprime... Współbieżność 11 / 58

12 Metody tworzenia wątków cd. 2 uruchamiamy wątek za pomocą PrimeRun p = new PrimeRun(143); new Thread(p).start(); Współbieżność 12 / 58

13 Metody tworzenia wątków w C++ Wątki mapują się jeden do jeden z wątkami systemu operacyjnego. Plik nagłówkowy <thread> namespace std { class thread; void swap(thread& x, thread& y) noexcept; namespace this_thread { thread::id get_id() noexcept; void yield() noexcept; template <class Clock, class Duration> void sleep_until(const chrono::time_point<clock, Duration>& abs_time); template <class Rep, class Period> void sleep_for(const chrono::duration<rep, Period>& rel_time); Współbieżność 13 / 58

14 Metody tworzenia wątków w C++ Klasa thread dostarcza mechanizm do tworzenia nowych wątków wykonania, do oczekiwania na zakończenie wątku, i inne operacje, które zarządzają i odpytują o stan wątku. Obiekt thread jednoznacznie reprezentuje konkretny wątek wykonania. Ta reprezentacja może być transferowana do innego obiektu thread w ten sposób, że żadne dwa obiekty thread nie reprezentują tego samego wątku wykonania jednocześnie. Wątek wykonania jest odłączony, kiedy żadeń z obiektów thread nie reprezentuje tego wątku. Obiekty klasy thread mogą być w stanie, który nie reprezentuje wątku wykonania (po wywołaniu domyślnego konstruktora, przesunięcia lub po pomyślnym wywołaniu detach lub join). namespace std { class thread { public: // types: class id; Współbieżność 14 / 58

15 Metody tworzenia wątków w C++ typedef implementation-defined native_handle_type; // See // construct/copy/destroy: thread() noexcept; template <class F, class...args> explicit thread(f&& f, Args&&... args); ~ thread(); thread(const thread&) = delete; thread(thread&&) noexcept; thread& operator=(const thread&) = delete; thread& operator=(thread&&) noexcept; // members: void swap(thread&) noexcept; bool joinable() const noexcept; void join(); void detach(); Współbieżność 15 / 58

16 Metody tworzenia wątków w C++ id get_id() const noexcept; native_handle_type native_handle(); // See // static members: static unsigned hardware_concurrency() noexcept; ; Współbieżność 16 / 58

17 Metody tworzenia wątków w C++ brak metody start // thread example #include <iostream> #include <thread> // std::cout // std::thread void foo() { // do stuff... void bar(int x) { // do stuff... Współbieżność 17 / 58

18 Metody tworzenia wątków w C++ int main() { std::thread first (foo); // spawn new thread that calls foo() std::thread second (bar,0); // spawn new thread that calls bar(0) std::cout << "main, foo and bar now execute concurrently...\n"; // synchronize threads: first.join(); // pauses until first finishes second.join(); // pauses until second finishes std::cout << "foo and bar completed.\n"; return 0; Współbieżność 18 / 58

19 Zakończenie programu Kiedy program kończy działanie? Program kończy działanie kiedy zajdzie jedna z możliwości: wszystkie wątki które nie są demonami (ang. daemon thread) kończą działanie jakiś wątek uruchomił metodę exit klasy Runtime lub System i metoda exit nie jest zabroniona przez Security Manager. Współbieżność 19 / 58

20 Section 3 Synchronizacja Synchronizacja 20 / 58

21 Monitory najprostszą metodą komunikacji między wątkami jest synchronizacja zaimplementowana za pomocą monitorów każdy obiekt w Javie jest powiązany z monitorem, który może być przez wątek zajmowany lub zwalniany Tylko jeden wątek w danym czasie może zajmować monitor. Każdy inny wątek chcący zająć ten monitor jest blokowany dopóki nie będzie mógł zająć tego monitora. Wątek t może zajmować konkretny monitor wiele razy. Każde zwolnienie cofa efekt jednego zajęcia. nie możemy zakładać żadnej konkretnej kolejności wątków chcących zająć monitor Instrukcja synchronized najpierw pobiera referencję do obiektu. Następnie próbuje zająć monitor tego obiektu (ang. lock action) i nie wykonuje się dalej dopóki nie zajmie monitora tego obiektu. Kiedy monitor zostanie zajęty wykonuje się blok instrukcji. Po wykonaniu bloku instrukcji operacja zwolnienia monitora jest automatycznie wykonywana na tym monitorze. Synchronizacja 21 / 58

22 Synchronizacja Metoda synchronized automatycznie próbuje zająć monitor podczas uruchomienia. Blok instrukcji jest wykonywany po zajęciu monitora. Jeśli metoda jest niestatyczna, jest zajmowany monitor instancji na której została wywołana metoda. Jeśli metoda jest statyczna to zajmowany jest monitor związany z obiektem klasy Class, który reprezentuje tę klasę. Po wykonaniu bloku instrukcji monitor jest zwalniany. Jak wygląda zajęcie monitora klasy? Synchronized przy metodzie statycznej lub synchronized(x.class) inne metody synchronizacji: volatile, klasy z pakietu java.util.concurrent. Synchronizacja 22 / 58

23 Metoda synchronizowana metoda synchronizowana zajmuje monitor przed jej wykonaniem dla metody klasowej (statycznej) zajmowany jest monitor, który jest związany z obiektem Class dla klasy z której pochodzi ta metoda dla metody instancyjnej zajmowany jest monitor związany z obiektem this (obiekt na którym zostaje wykonana metoda) class Test { int count; synchronized void bump() { count++; static int classcount; static synchronized void classbump() { classcount++; Synchronizacja 23 / 58

24 Metoda synchronizowana cd. Ten sam efekt co w poprzednim przykładzie class BumpTest { int count; void bump() { synchronized (this) { count++; static int classcount; static void classbump() { try { synchronized (Class.forName("BumpTest")) { classcount++; catch (ClassNotFoundException e) { Synchronizacja 24 / 58

25 Metoda synchronizowana cd. 2 Co by się stało gdyby metody get i put nie były synchronizowane? Np. (wątek:instrukcja) (1:1, 2:1, 1:2, 2:2) public class Box { private Object boxcontents; //reference to any object public synchronized Object get() { Object contents = boxcontents; boxcontents = null; return contents; public synchronized boolean put(object contents) { if (boxcontents!= null) return false; // 1 boxcontents = contents; // 2 return true; Synchronizacja 25 / 58

26 Metoda synchronizowana cd. 3 Czy konstruktor może być synchronizowany? Nie i nie ma takiej potrzeby, ponieważ obiekt podczas tworzenia jest blokowany i jest dostępny dla innych wątków dopiero po utworzeniu. Synchronized nie może być użyte w metodzie dla metod domyślnych i statycznych w interfejsie. monitor jest zwalniany kiedy synchronizowane instrukcje lub wywołania synchronizowanych metod zakończą się wyrzuceniem wyjątku Synchronizacja 26 / 58

27 Instrukcja synchronized synchronized (Expression) Block. Typ Expression musi być typem referencyjnym. Najpierw jest obliczane Expression. inne wątki w dalszym ciągu mają dostęp do pól obiektów i do metod niesynchronizowanych class Test { public static void main(string[] args) { Test t = new Test(); synchronized(t) { synchronized(t) { System.out.println("made it!"); Synchronizacja 27 / 58

28 Volatile język Java umożliwia wątkom dostęp do zmiennych współdzielonych pole może być zadeklarowane volatile, wtedy model pamięci Javy zapewnia, że wszystkie wątki widzą tą samą wartość tej zmiennej dla pola final nie można deklarować modyfikatora volatile (błąd kompilacji) class Test { static int i = 0, j = 0; static void one() { i++; // i1 j++; // i2 static void two() { System.out.println("i = " + i); // i3 System.out.println("j = " + j); // i4 Synchronizacja 28 / 58

29 Volatile cd. Kiedy jeden wątek wielokrotnie wywołuje metodę one (ale nie więcej niż Integer.MAX_VALUE), a drugi wątek wielokrotnie wywołuje metodę two, wtedy metoda two sporadycznie będzie wyświetlała wartość j która jest większa niż wartość i przykład ten nie zawiera synchronizacji, zmienne współdzielone i oraz j mogą być uaktualnione w innej kolejności (w cache wątku wywołującego metodę two) np. dla wykonania (i1,i2,i1,i2,i3,i4) lub kompilator może zamienić kolejność instrukcji i1 i i2 np. wykonanie (i2,i1,i2,i3,i4,i1) lub przy wielokrotnie wywołanej metodzie one() po odczycie i przed odczytem j np. (i3,i1,i2,i1,i2,i4) jest możliwość, że i będzie większe od j, np. dla wykonania (i1,i3,i4,i2) Synchronizacja 29 / 58

30 Volatile cd. 2 aby temu zapobiec pierwszą możliwością jest deklaracja metod one i two jako synchronizowanych class Test { static int i = 0, j = 0; static synchronized void one() { i++; // 1 j++; // 2 static synchronized void two() { System.out.println("i=" + i + " j = " + j); Synchronizacja 30 / 58

31 Volatile cd. 3 kod ten gwarantuje to, że obie metody nie będą wykonywały się równolegle a także gwarantuje to, że zmienne współdzielone i oraz j są uaktualnione w pamięci współdzielonej przed końcem metody one oraz wątek 2 pobierze te wartości z pamięci współdzielonej, a nie ze swojego cache w rejestrze druga możliwość to deklaracja zmiennych i oraz j jako volatile class Test { static volatile int i = 0, j = 0; static void one() { i++; // 1 j++; // 2 static void two() { System.out.println("i=" + i + " j = " + j); Synchronizacja 31 / 58

32 Volatile cd. 4 metody one oraz two mogą wykonywać się równolegle, ale jest gwarancja tego, że dostęp do zmiennych współdzielonych i oraz j występuje dokładnie tyle razy i dokładnie w tej samej kolejności, w jakiej pojawiają się podczas wykonywania tekstu programu przez każdy wątek, dlatego wartość j może być większa od wartości i, tylko z powodu wielokrotnego wywołania one() po odczycie i przed odczytem j Synchronizacja 32 / 58

33 Volatile cd. 5 pojedynczy zapis do zmiennej typu long czy double, które nie są volatile jest traktowany jako dwa osobne zapisy, do każdej połówki 32 bitowej osobno. Może dojść do sytuacji kiedy wątek widzi pierwszą połówkę z jednego zapisu, a drugą połówkę z innego zapisu zapis i odczyt volatile long i double są zawsze atomiczne volatile używamy nie tylko do typów prostych ale także do referencji Synchronizacja 33 / 58

34 Volatile w C++ volatile to podpowiedź do implementacji do unikania agresywnej optymalizacji z użyciem obiektu, ponieważ wartość obiektu mogłaby się zmienić w sposób niewykrywalny przez implementację. Ponadto, w niektórych implementacjach volatile mogłoby wskazywać, że specjalne instrukcje maszynowe są konieczne do dostępu do obiektu. volatile nie służy do synchronizacji w c++ Synchronizacja 34 / 58

35 Przerwania każdy wątek posiada status przerwania wątek może być przerwany za pomocą wyrzucenia wyjątku InterruptedException i wtedy status przerwania jest ustawiany na false akcja przerwania występuje podczas wywołania Thread.interrupt albo innych metod, które ją wywołują jak np. ThreadGroup.interrupt Niech wątek t wywołuje u.interrupt dla pewnego wątku u, gdzie t i u mogą być te same. Ta akcja spowoduje ustawienie statusu przerwania dla u na true (akcja przerwania ustawia status, ale nie przerywa wątku) metodą Thread.isInterrupted możemy sprawdzić status przerwania, a metodą statyczną Thread.interrupted wyczyścić ten status. Synchronizacja 35 / 58

36 Przerwania cd. przy intensywnych obliczeniach można sprawdzać co jakiś czas czy nie nadszedł sygnał przerwania, metoda Thread.interrupted() sprawdza i zmienia status przerwania na false for (int i = 0; i < inputs.length; i++) { heavycrunch(inputs[i]); if (Thread.interrupted()) { // We ve been interrupted: no more crunching. return; można również wyrzucić wyjątek if (Thread.interrupted()) { throw new InterruptedException(); Synchronizacja 36 / 58

37 Join metoda join pozwala na oczekiwanie jednego wątku na zakończenie innego wątku, uruchomienie tej metody na tym samym wątku powoduje zatrzymanie wątku Synchronizacja 37 / 58

38 Section 4 Zbiory oczekujące Zbiory oczekujące 38 / 58

39 Zbiory oczekujące Każdy obiekt posiada zbiór oczekujący (ang. wait set), jest to zbiór wątków. Po utworzeniu obiektu ten zbiór jest pusty. Operacje które dodają lub usuwają wątki z tego zbioru są atomiczne. Metody służące do manipulacji tym zbiorem: Object.wait, Object.notify, Object.notifyAll. akcja oczekiwania (ang. wait action) występuje po wywołaniu wait(), lub wait(long millisecs), lub wait(long millisecs, int nanosecs) wątek powraca normalnie ze stanu oczekiwania, kiedy powraca bez wyrzucania wyjątku InterruptedException wprowadźmy oznaczenia wątek t, obiekt m, na którym będzie wykonywane wait(), n to liczba zajęć monitora przez wątek t na obiekcie m, które nie zostały zwolnione Zbiory oczekujące 39 / 58

40 Zbiory oczekujące cd. Jedna z następujących akcji zachodzi po wywołaniu wait: jeśli n jest zero, jest wyrzucany wyjątek IllegalMonitorStateException kiedy wątek zostaje przerwany, jest wyrzucany wyjątek InterruptedException i status przerwania wątku t jest ustawiany na false zachodzi następująca sekwencja wątek t zostaje dodany do zbioru oczekującego obiektu m, następnie wykonuje n zwolnień monitora na m wątek t nie wykonuje dalszych instrukcji, dopóki nie zostanie usunięty ze zbioru oczekującego dla obiektu m wątek t wykonuje n zajęć monitora na obiekcie m w jaki sposób wątek może zostać usunięty ze zbioru oczekującego? zostanie wykonana akcja notify na m lub notifyall na m lub interrupt na t wewnętrzna akcja zależna od implementacji, tzw. spurious wake-ups, czyli usunięcie ze zbioru oczekującego bez wyraźnej instrukcji Zbiory oczekujące 40 / 58

41 Akcja powiadomienia Akcja powiadomienia następuje po wywołaniu metod notify, notifyall. Jedna z następujących akcji zachodzi po wywołaniu notify: jeśli n jest zero, jest wyrzucany wyjątek IllegalMonitorStateException jeśli n > 0, i kiedy zbiór oczekujący jest niepusty, jest wybierany wątek u z tego zbioru i usuwany. Nie ma gwarancji, który zostanie wybrany wątek do wybudzenia. jeśli n > 0 i mamy akcję notifyall, wtedy wszystkie wątki zostaną usunięte ze zbioru oczekującego. Tylko jeden z nich zajmie monitor. Zbiory oczekujące 41 / 58

42 Akcja powiadomienia cd. public void guardedjoy() { // Simple loop guard. Wastes // processor time. Don t do this! while(!joy) { System.out.println("Joy has been achieved!"); Zbiory oczekujące 42 / 58

43 Akcja powiadomienia cd. 2 zawsze musimy mieć pętlę sprawdzającą warunek na który czekamy ze względu na fałszywe wybudzenia synchronizacja musi być na tym samym obiekcie co wait public synchronized void guardedjoy() { // This guard only loops once for each special //event, which may not // be the event we re waiting for. while(!joy) { try { wait(); catch (InterruptedException e) { System.out.println("Joy and efficiency have been achieved!"); Zbiory oczekujące 43 / 58

44 Akcja powiadomienia cd. 3 synchronizacja musi być na tym samym obiekcie co notifyall public synchronized notifyjoy() { joy = true; notifyall(); Zbiory oczekujące 44 / 58

45 Przerwania dla oczekiwania jeśli wątek jest wybudzany i przerywany podczas oczekiwania to może: powrócić normalnie z wait, mając ustawione przerwanie oczekujące (wywołanie Thread.interrupted zwróci true) powrócić z wait wyrzucając InterruptedException Wątek nie musi resetować statusu przerwania i może powrócić normalnie z wait. Zakładając, że zbiór s wątków jest w zbiorze oczekującym obiektu m i inny wątek wykonał notify na m, wtedy co najmniej jeden z wątków w s musi normalnie powrócić z wait, lub wszystkie wątki w s muszą wyjść z wait z wyrzuceniem InterruptedException Z tego wynika, że jeśli wątek jest zarówno przerywany i wybudzany przez notify, i wątek wychodzi z wait przez wyrzucenie wyjątku InterruptedException, to jakiś inny wątek w zbiorze oczekującym musi być wybudzony. Zbiory oczekujące 45 / 58

46 Sleep i yield Thread.sleep powoduje uśpienie wątku na określony czas nie ma wymogów co do zapisu rejestrów do wspólnej pamięci przed wywołaniem Thread.sleep czy Thread.yield while (!this.done) Thread.sleep(1000); Zbiory oczekujące 46 / 58

47 Collections.synchronizedList() wersje thread-safe popularnych kolekcji jako opakowania: Collections.synchronizedList(List<T>), Collections.synchronizedMap(Map<K, V>), Collections.synchronizedSet(Set<T>), itd. jeśli wiele wątków uzyskuje dostęp do ArrayList (czyli co najmniej 2), i jeden z nich zmienia ją strukturalnie, lista musi być synchronizowana zewnętrznie. Z reguły synchronizowanie odbywa się na obiekcie który enkapsuluje listę (czyli niekoniecznie). Jeśli taki obiekt nie istnieje, lista powinna być synchronizowana za pomocą metody Collections.synchronizedList. Z opisu wynika, że wszystkie metody listy muszą być wtedy synchronizowane (np. getsize()) Zbiory oczekujące 47 / 58

48 Pytanie Jak wybudzić konkretny wątek? Zbiory oczekujące 48 / 58

49 Odpowiedź Można używać zbiorów oczekujących dla dowolnych obiektów, więc każdy wątek może mieć zbiór oczekujący, np. na obiekcie wątku, i wywołujemy notify() na odpowiednim obiekcie Zbiory oczekujące 49 / 58

50 Pytanie Czy mechanizm wait/notify mógłby być zaimplementowany w klasie Thread? Zbiory oczekujące 50 / 58

51 Odpowiedź Klasa Thread dziedziczy po klasie Object, więc posiada mechanizm wait/notify. A więc czy można byłoby przenieść mechanizm wait/notify z Object do Thread? Można przeprowadzić eksperyment i ograniczyć korzystanie w programie z mechanizmu wait/notify tylko do obiektów Thread. Dodatkowo sensownie byłoby zrezygnować wtedy ze zbioru oczekującego i zastąpić go informacją czy wątek związany z obiektem Thread jest w stanie oczekiwania czy nie. Posiadanie zbioru wątków oczekujących w danym wątku mogłoby być mylące. Zbiory oczekujące 51 / 58

52 Odpowiedź cd. W eksperymencie można ograniczyć zbiór oczekujący tak aby tylko wątek związany z danym obiektem Thread mógł do niego należeć, dlatego ograniczamy możliwość wywoływania wait na danym obiekcie Thread do wątku, z którym jest powiązany dany obiekt. Możemy zrealizować ten postulat ograniczając wywoływanie wait do postaci Thread.currentThread.wait(). Formalnie, aktualnie akcja oczekiwania jest zależna od wątku i obiektu w(t, o). Po tej zmianie chcemy aby akcja oczekiwania była zależna tylko od wątku w(t), a więc w poprzednim modelu usuwamy możliwość podania dowolnego obiektu i używamy obiektu domyślnego związanego z obiektem Thread danego wątku t. Trudności na jakie natrafiamy: wątek chcący powiadomić inny wątek musi posiadać referencję do tego wątku. Gdy chcemy wybudzić grupę wątków, musimy mieć listę referencji do oczekujących wątków. W aktualnym rozwiązaniu ta lista wątków jest wewnętrznie zaimplementowana w Javie w postaci zbioru oczekującego. Zbiory oczekujące 52 / 58

53 Odpowiedź cd. kolejną wadą tego rozwiązania byłaby mniejsza separacja aspektów uruchamiania programu od kodu programu, musimy w kodzie utrzymywać listę wątków do wybudzenia kolejną wadą jest to, że wątek nie ma wiedzy, w jakim celu aktualnie jest w stanie oczekiwania, ponieważ oczekiwanie nie jest związane z obiektem, który może zawierać cel oczekiwania mechanizm wait/notify musi być synchronizowany, a synchronizacja w Javie jest zaimplementowana dla dowolnego obiektu, a więc w eksperymencie używana byłaby synchronizacja tylko na obiektach Thread. decyzja podjęta na etapie tworzenia specyfikacji języka Java Zbiory oczekujące 53 / 58

54 Pytanie Czy w zbiorze oczekującym jakiegoś obiektu dany wątek może pojawić się więcej niż jeden raz? Zbiory oczekujące 54 / 58

55 Odpowiedź Po wywołaniu wait wątek nie wykonuje dalszych instrukcji, dopóki nie zostanie usunięty ze zbioru oczekującego, więc nie ma możliwości wywołania dwukrotnie wait(). Ponadto, wątek jednocześnie nie może być w zbiorach oczekujących dwóch różnych obiektów. Zbiory oczekujące 55 / 58

56 Pytanie Wg specyfikacji języka Java, wait/notify muszą być synchronizowane na tym samym obiekcie, na którym są wywoływane (albo zostanie rzucony wyjątek IllegalMonitorStateException). Dlaczego wait/notify muszą być synchronizowane i czy muszą być synchronizowane na tym samym obiekcie, który zawiera zbiór oczekujący? Zbiory oczekujące 56 / 58

57 Odpowiedź class BlockingQueue { Queue<String> buffer = new LinkedList<String>(); public void give(string data) { buffer.add(data); // 1 notify(); // 2 Since someone may be waiting in take! public String take() throws InterruptedException { while (buffer.isempty()) // 3 don t use "if" due to spurious wakeups. wait(); // 4 return buffer.remove(); // 5 Zbiory oczekujące 57 / 58

58 Pytania Przykład dlaczego wait i notify muszą być synchronizowane. (C:3, P:1, P:2, C:4). Zakłada się, że wait jest powiązane z warunkiem. Jeśli tylko notify byłoby synchronizowane, widzimy od razu, że otrzymujemy to samo. A jeśli tylko wait byłoby synchronizowane? Gdy obie akcje byłyby synchronizowane, wtedy (C:3, C:4, P:1, P:2, C:5). Zbiory oczekujące 58 / 58