Proaktywne

Pakiet równoległy ProActive
Deweloperzy ActiveEon, Inria , OW2
Wersja stabilna
10,0 (F-zero) / 12 lipca 2019 r .; 3 lata temu ( 2019-07-12 )
Napisane w Jawa
System operacyjny Międzyplatformowe
Typ Harmonogram zadań
Licencja AGPL
Strona internetowa www.activeeon.com _ _

ProActive Parallel Suite to oprogramowanie typu open source do orkiestracji obciążeń korporacyjnych , będące częścią społeczności OW2 . Model przepływu pracy umożliwia zdefiniowanie zestawu plików wykonywalnych lub skryptów , napisanych w dowolnym języku, wraz z ich zależnościami, dzięki czemu ProActive Parallel Suite może planować i koordynować wykonania, optymalizując wykorzystanie zasobów obliczeniowych .

Pakiet ProActive Parallel Suite jest oparty na wzorcu projektowym „ obiektów aktywnych ” (patrz Obiekty aktywne ) w celu optymalizacji dystrybucji zadań i tolerancji błędów.

Kluczowe funkcje pakietu ProActive Parallel Suite

  • Przepływy pracy ułatwiają równoległość zadań (Java, skrypty lub natywne pliki wykonywalne), uruchamiając je na zasobach spełniających różne ograniczenia (takie jak akceleracja GPU, biblioteka lub lokalizacja danych).
  • Dostępne są interfejsy internetowe do projektowania i wykonywania przepływów pracy oraz zarządzania zasobami obliczeniowymi. RESTful API zapewnia interoperacyjność z aplikacjami korporacyjnymi.
  • Zasoby obliczeniowe mogą być sfederowane (chmura, klastry, infrastruktury zwirtualizowane, komputery stacjonarne) w jedną infrastrukturę wirtualną. Zapewnia automatyczne skalowanie i ułatwia strategie zarządzania zasobami.
  • Interoperacyjność jest zapewniona dzięki heterogenicznym przepływom pracy, w których zadania mogą być uruchamiane na różnych platformach, w tym Windows, Mac i Linux.

Framework ProActive Java i model programowania

Model został stworzony przez Denisa Caromela, profesora Uniwersytetu w Nicei Sophia Antipolis . Kilka rozszerzeń modelu zostało później wykonanych przez członków zespołu OASIS w INRIA . Książka A Theory of Distributed Objects przedstawia rachunek ASP, który formalizuje funkcje ProActive i zapewnia formalną semantykę rachunku, wraz z właściwościami wykonywania programu ProActive.

Obiekty aktywne

Obiekty aktywne to podstawowe jednostki aktywności i dystrybucji używane do budowania współbieżnych aplikacji przy użyciu ProActive. Aktywny obiekt działa z własnym wątkiem . Ten wątek wykonuje tylko metody wywołane na tym aktywnym obiekcie przez inne aktywne obiekty oraz metody pasywnych obiektów podsystemu, który należy do tego aktywnego obiektu. Dzięki ProActive programista nie musi jawnie manipulować obiektami Thread, w przeciwieństwie do standardowej Javy.

Aktywne obiekty mogą być tworzone na dowolnym hoście biorącym udział w obliczeniach. Po utworzeniu aktywnego obiektu jego aktywność (fakt, że działa z własnym wątkiem) i jego lokalizacja (lokalna lub zdalna) są doskonale przejrzyste. Każdym obiektem aktywnym można manipulować tak, jakby był bierną instancją tej samej klasy.

Obiekt aktywny składa się z dwóch obiektów: body i standardowego obiektu Java. Ciało nie jest widoczne z zewnątrz aktywnego obiektu.

Ciało jest odpowiedzialne za odbieranie wywołań (lub żądań ) na aktywnym obiekcie i przechowywanie ich w kolejce oczekujących wywołań. Wykonuje te wywołania w kolejności określonej przez zasady synchronizacji. Jeśli zasady synchronizacji nie są określone, połączenia są zarządzane na zasadzie „ First in, first out ” (FIFO).

Wątek aktywnego obiektu następnie wybiera metodę z kolejki oczekujących żądań i wykonuje ją. Wewnątrz aktywnego obiektu nie ma równoległości; jest to ważna decyzja w projekcie ProActive, umożliwiająca użycie warunków „pre-post” i niezmienników klas .

Po stronie podsystemu, która wysyła wywołanie do aktywnego obiektu, aktywny obiekt jest reprezentowany przez proxy . Proxy generuje przyszłe obiekty reprezentujące przyszłe wartości, przekształca wywołania w obiekty Request (pod względem metaobiektu jest to reifikacja ) i wykonuje głębokie kopie pasywnych obiektów przekazywanych jako parametry.

Baza obiektów aktywnych

ProActive to biblioteka przeznaczona do tworzenia aplikacji w modelu wprowadzonym przez Eiffel//, będącym równoległym rozszerzeniem języka programowania Eiffel .

W tym modelu aplikacja jest podzielona na podsystemy . Istnieje jeden aktywny obiekt (a zatem jeden wątek) dla każdego podsystemu i jeden podsystem dla każdego aktywnego obiektu (lub wątku). Każdy podsystem składa się zatem z jednego obiektu aktywnego i dowolnej liczby obiektów pasywnych — prawdopodobnie żadnych obiektów pasywnych. Wątek jednego podsystemu wykonuje tylko metody w obiektach tego podsystemu. Nie ma „współdzielonych obiektów pasywnych” między podsystemami.

Te funkcje wpływają na topologię aplikacji. Spośród wszystkich obiektów tworzących podsystem — obiektu aktywnego i obiektu pasywnego — tylko obiekt aktywny jest znany obiektom spoza podsystemu. Wszystkie obiekty, zarówno aktywne, jak i pasywne, mogą mieć odniesienia do obiektów aktywnych. Jeśli obiekt o1 ma odniesienie do obiektu pasywnego o2 , to o1 i o2 są częścią tego samego podsystemu.

Model: Sekwencyjny, wielowątkowy, rozproszony

Ma to również wpływ na semantykę przekazywania komunikatów między podsystemami. Gdy obiekt w podsystemie wywołuje metodę na obiekcie aktywnym, parametry wywołania mogą być referencjami na obiektach pasywnych podsystemu, co prowadziłoby do wspólnych obiektów pasywnych. Właśnie dlatego obiekty pasywne przekazywane jako parametry wywołań obiektów aktywnych są zawsze przekazywane przez deep-copy . Z drugiej strony obiekty aktywne są zawsze przekazywane przez referencję . Symetrycznie dotyczy to również obiektów zwracanych z metod wywoływanych na obiektach aktywnych.

Dzięki koncepcjom wywołań asynchronicznych , kontraktów terminowych i braku udostępniania danych aplikacja napisana w ProActive nie wymaga żadnych zmian strukturalnych — właściwie prawie żadnych — niezależnie od tego, czy działa w środowisku sekwencyjnym , wielowątkowym czy rozproszonym .

Asynchroniczne połączenia i kontrakty futures

Gdy tylko jest to możliwe, wywołanie metody na aktywnym obiekcie jest reifikowane jako żądanie asynchroniczne. Jeśli nie jest to możliwe, połączenie jest synchroniczne i blokuje się do czasu otrzymania odpowiedzi. Jeśli żądanie jest asynchroniczne, natychmiast zwraca przyszły obiekt .

Przyszły obiekt działa jako element zastępczy dla wyniku wywołania metody, która nie została jeszcze wykonana. W konsekwencji wątek wywołujący może kontynuować wykonywanie swojego kodu, o ile nie musi wywoływać metod na zwróconym obiekcie. W razie potrzeby wątek wywołujący jest automatycznie blokowany, jeśli wynik wywołania metody nie jest jeszcze dostępny. Chociaż przyszły obiekt ma strukturę podobną do obiektu aktywnego, przyszły obiekt nie jest aktywny. Ma tylko Stub i Proxy.

Przykład kodu

Poniższy fragment kodu podkreśla pojęcie przyszłych obiektów. Załóżmy, że użytkownik wywołuje metodę foo i metodę bar z aktywnego obiektu a ; metoda foo zwraca void, a metoda bar zwraca obiekt klasy V : 



 




    


 // jednokierunkowa asynchroniczna komunikacja z (zdalnym) AO a  // żądanie jest wysyłane do  a  .  foo  (  parametr  );  // wpisana asynchroniczna komunikacja z wynikiem.  // v to najpierw oczekiwana Przyszłość, którą należy w przejrzysty sposób wypełnić po  // obsłudze żądania i odpowiedzi  V  v  =  a  .  pasek  (  parametr  );  ...  // użycie wyniku wywołania asynchronicznego.  // jeśli v jest wciąż wyczekiwaną przyszłością, uruchamia automatyczne 

  // czekaj: oczekiwanie na konieczność  v  .  ojej  (  param  );

Kiedy foo jest wywoływane na aktywnym obiekcie a , zwraca natychmiast (ponieważ bieżący wątek nie może wykonywać metod w innym podsystemie). Podobnie, gdy bar jest wywoływany na a , zwraca natychmiast, ale wyniku v nie można jeszcze obliczyć. Zwracany jest przyszły obiekt, który jest symbolem zastępczym dla wyniku wywołania metody. Z punktu widzenia podsystemu wywołującego nie ma różnicy między przyszłym obiektem a obiektem, który zostałby zwrócony, gdyby to samo wywołanie zostało skierowane do obiektu pasywnego.

Po zwróceniu obu metod wątek wywołujący kontynuuje wykonywanie swojego kodu tak, jakby wywołanie zostało skutecznie wykonane. Rolą przyszłego mechanizmu jest blokowanie wątku wywołującego, gdy gee jest wywoływana na v , a wynik nie został jeszcze ustawiony: ta polityka synchronizacji między obiektami jest znana jako wait-by-necessity .

Zobacz też

Dalsza lektura

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=ProActive&oldid=1095130430 ”