Programowanie asynchroniczne jest o wiele bardziej filozofią niż kolejną sztuczką programistyczną. Podczas gdy twoje ostatnie pytanie przyciągało odpowiedzi głównie na temat aspektów programowania, a moja odpowiedź była samotnikiem, ponieważ był głównie teoretyczny, staram się dać ci nową perspektywę, opierając się na tej samej linii, ale wyjaśnienia, a nie tylko odniesienia.
Ten dotyczy kilku podstawowych podstaw programowania i programowania asynchronicznego.
Załóżmy, że idziesz do piekarni (i zakładając, że ciasto zostanie przygotowane po złożeniu zamówienia) - masz dwie możliwości: albo poczekasz, aż ciasto będzie gotowe, albo wydasz zamówienie i wrócisz do domu i odbierzesz później, kiedy będzie gotowy. Pierwszy (czekaj) to metoda synchroniczna, a później metoda asynchroniczna . Nie trzeba dodawać, że ten przykład stanowi dobre odniesienie do tego, dlaczego należy używać metod asynchronicznych zamiast synchronicznych.
Programowanie oparte na zdarzeniach jest tylko jednym ze sposobów budowania systemów asynchronicznych i nie jest tylko użytecznym wzorcem projektowym, ale raczej wzorcem architektonicznym. Wymieniam przypadki, w których teorię tę stosuje się w praktycznie użyteczny sposób - mając nadzieję, że przyniesie ona trochę jasności
Jednym z pierwszych przykładów systemów asynchronicznych jest system IO systemu Unix. Chociaż wiemy read(), write()a nawet select()wywołuje bloki przepływu programu, ale w systemie operacyjnym są one asynchroniczne, tj. Jądro ogólnie wie, że urządzenie blokowe (inaczej dysk twardy) zajmie trochę czasu, aby wypełnić bufor, dopóki procesor nie będzie wolny z tego odpowiedniego wątku, a zatem wątek jest zaparkowany jako (niegotowy). Patrz 1. Moris Bach „Projekt systemu operacyjnego Unix”
Innym najczęstszym przykładem jest większość platform interfejsu użytkownika. Tutaj wszystkie kliknięcia użytkownika są najpierw wywoływane przez kontroler, który z kolei wywołuje odpowiednią aplikację. Ważną rzeczą jest to, że oddzwanianie nie powinno powodować oczekiwania na oddzwanianie, w przeciwnym razie system zawiesi się. Oddzwonienie z kontrolera interfejsu użytkownika do back-endów jest zwykle asynchroniczne, jeśli wymaga dużego przetwarzania.
Innym dobrym przykładem programowania asynchronicznego (jako czysty wzorzec projektowy) jest Obiekt Aktywny. Obiekt aktywny to taki, który ma własny prywatny wątek, dzięki czemu można przechowywać wiele żądań w kolejce i wykonywać je pojedynczo. Zobacz ten artykuł: Aktywny obiekt . Ten wzorzec jest szeroko stosowany od oprogramowania korporacyjnego po platformy mobilne. Popularne platformy Java / EJB i .NET pozwalają na lokalne lub zdalne wywoływanie metod asynchronicznych, które zasadniczo pozwalają, aby normalne obiekty stały się obiektami aktywnymi. Aktywne obiekty były obecne już w Symbian: Aktywne obiekty w Symbian OS autorstwa Aapo Haapanena (patrz też: Aktywne obiekty w Symbian ). To jest teraz również obecne wAndroid ).
Oprócz obiektu aktywnego ten sam autor Douglas C. Schmidt opracował wiele innych prac, które są innymi podobieństwami do obiektu aktywnego i są również wzorcami asynchronicznymi. Zobacz to Wzorce obsługi zdarzeń, a pełne konto jest dostępne w jego książce Architektura oprogramowania zorientowana na wzorce: Wzory dla obiektów współbieżnych i sieciowych - V2
Kiedy dany obiekt potrzeby powrotu API, podczas pracy w tle, aby właściwie wykonać pracę, zwykle metodologia jest mieć wielowątkowy system do osiągnięcia tego celu. Systemy wątkowe są obecne wszędzie, od C (posix), C ++ ( boost ) do Java, C # i tak dalej. Aktywny obiekt jest w zasadzie tylko abstrakcją, która może to ukryć. Zobacz, dlaczego implementacje obiektów aktywnych są lepsze niż nagie wątki. Kolejna dobra lektura .
Ale ta koncepcja wykracza poza wątki lub obiekty wewnątrz aplikacji i staje się asynchroniczna. Jednym z najlepszych zastosowań jest w systemach rozproszonych, w których dwie aplikacje niekoniecznie muszą na siebie czekać na koordynację. Dobre stare (lub nie tak dobre, jakkolwiek na to nie spojrzeć) RPC było synchroniczne. [oczywiście są też inne asynchroniczne RPC ]. Ale nowoczesne alternatywy, takie jak oprogramowanie pośredniczące zorientowane na wiadomości, są naprawdę asynchroniczne z dobrych powodów.
Ostatni, ale może być najbardziej interesujący, to programowanie Agentów, które może skorzystać z asynchronicznego modelu komunikacji .
Podczas gdy programowanie asynchroniczne wygląda seksownie , tworzy własną złożoność, w tym:
- ramy przekazywania wartości zwracanej
- dodatkowy narzut komunikacji
- dodatkowa potrzeba synchronizacji konstrukcji
- możliwość impasu, wyścigów itp., jeśli coś nie pójdzie dobrze.
... i tak dalej.
Zawsze należy go używać tylko z prawdziwych powodów.
Kiedy więc należy używać modelu asynchronicznego? Kiedy należy umieścić wątek w tle i zezwolić abonentowi na przejście w tryb asynchroniczny? Oto kilka dobrych zasad dotyczących kciuka, gdy ma on zastosowanie (ale nie jest kompletny)
Gdy system chce zastosować ścisłą poważną rozmowę o zasobach: na przykład chcesz zachować bezwzględnie ustaloną liczbę wątków. Wzorzec asynchroniczny wymusza na systemie wdrożenie kolejki.
Gdy osoba dzwoniąca musi zrobić „inne przydatne rzeczy do zrobienia”, rzeczywiście jest to autentyczne. Tak wiele razy drugi wątek, nawet jeśli został odblokowany, nie zrobi nic użytecznego i zawiesi się na odpytywaniu o wyniki. To rzeczywiście może pochłaniać więcej procesora niż podstawowy model synchroniczny.
Gdy potrzebujesz wyższego poziomu niezawodności w systemach rozproszonych. (patrz Oprogramowanie pośrednie zorientowane na wiadomości ).